|
From: Logan G. <log...@gm...> - 2004-11-07 16:12:11
|
Hello list;
I have come across a strange behaviour in valgrind. It seems that if
I call strerror_r from a forked process that was spawned in a thread I
get complaints about an invalid memory access. What is strange is if
I make the same strerror_r call from outside of the forked process I
do not get any memory complaints.
==9878== Thread 2:
==9878== Invalid read of size 4
==9878== at 0x1B96F272: getenv (in /lib/libc-2.3.2.so)
==9878== by 0x1B968779: guess_category_value (in /lib/libc-2.3.2.so)
==9878== by 0x1B967D38: __dcigettext (in /lib/libc-2.3.2.so)
==9878== by 0x1B9679E4: __dcgettext_internal (in /lib/libc-2.3.2.so)
==9878== by 0x1B9BF1C8: strerror_r (in /lib/libc-2.3.2.so)
==9878== by 0x8048677: blowup_thread_main (test.c:62)
==9878== by 0x1B90B9F0: thread_wrapper (vg_libpthread.c:867)
==9878== by 0xB000EF61: do__quit (vg_scheduler.c:1872)
==9878== Address 0x52BFEA3C is not stack'd, malloc'd or (recently) free'd
I have verified this behaviour on SuSE 9.1 with valgrind 2.0.0 and on
Redhat 8.0 with valgrind 2.2.0. Both produce slightly different, but
more a less the same output.
I have attached a simple program that can reproduce the output on my
system each time.
-- snip --
#define _REENTRANT
#define _THREAD_SAFE
#include <stdio.h>
#include <stdarg.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
void create_blowup_thread (void);
void *blowup_thread_main (void *data);
void
create_blowup_thread(void)
{
int error;
pthread_t dummy_thread_handle;
pthread_attr_t create_detached_attr;
if ((pthread_attr_init(&create_detached_attr)) != 0)
{
printf("Unable to create attr.\n");
exit(EXIT_FAILURE);
}
if ((pthread_attr_setdetachstate(&create_detached_attr,
PTHREAD_CREATE_DETACHED)) != 0)
{
printf("Unable to set detach state.\n");
exit(EXIT_FAILURE);
}
error = pthread_create(&dummy_thread_handle, &create_detached_attr,
blowup_thread_main, NULL);
if (error != 0)
{
printf("Unable to create thread.\n");
exit(EXIT_FAILURE);
}
sleep(5);
exit(EXIT_SUCCESS);
}
void *
blowup_thread_main(data)
void *data;
{
char *buf;
int error;
switch (error = fork())
{
case -1:
printf("Unable to fork.\n");
break;
case 0:
buf = malloc(1024);
strerror_r(2, buf, 1023);
exit(EXIT_SUCCESS);
break;
default:
break;
}
return NULL;
}
int
main(argc, argv)
int argc;
char **argv;
{
create_blowup_thread();
exit(EXIT_SUCCESS);
}
-- snip --
Compile with:
gcc -o test test.c -lpthread -g
|
|
From: Tom H. <th...@cy...> - 2004-11-07 16:54:04
|
In message <761...@ma...>
Logan Gabriel <log...@gm...> wrote:
> I have come across a strange behaviour in valgrind. It seems that if
> I call strerror_r from a forked process that was spawned in a thread I
> get complaints about an invalid memory access. What is strange is if
> I make the same strerror_r call from outside of the forked process I
> do not get any memory complaints.
>
> ==9878== Thread 2:
> ==9878== Invalid read of size 4
> ==9878== at 0x1B96F272: getenv (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B968779: guess_category_value (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B967D38: __dcigettext (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B9679E4: __dcgettext_internal (in /lib/libc-2.3.2.so)
> ==9878== by 0x1B9BF1C8: strerror_r (in /lib/libc-2.3.2.so)
> ==9878== by 0x8048677: blowup_thread_main (test.c:62)
> ==9878== by 0x1B90B9F0: thread_wrapper (vg_libpthread.c:867)
> ==9878== by 0xB000EF61: do__quit (vg_scheduler.c:1872)
> ==9878== Address 0x52BFEA3C is not stack'd, malloc'd or (recently) free'd
Good grief. You're the third person in as many days to run into this
which is pretty impressive considering this bug has been in the code
forever and only one person has ever reported it before this weekend.
See bug 85625 for my analysis and a patch which I think will fix it.
You might also want to consider whether you really want to be doing
this at all - if you fork in a threaded program and then don't do
an exec then you are leaking the stacks of the other threads in the
child process as they will not be deallocated.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|