|
From: Aleksander S. <A....@os...> - 2006-03-28 10:34:32
|
Hi,
This short, simple and correct (I hope :)) test program fails under
Valgrind:
// #includes ommited to make it shorter...
#define STACK_SIZE 40000
void* thr_func(void* unused)
{
printf("new thread is alive\n");
return NULL;
}
int main()
{
pthread_attr_t attr;
void* stack;
pthread_t new_thread;
pthread_attr_init(&attr);
stack = malloc(STACK_SIZE);
pthread_attr_setstack(&attr, stack, STACK_SIZE);
if(pthread_create(&new_thread, &attr, thr_func, NULL)!=0)
fprintf(stderr, "error while creating thread\n");
pthread_join(new_thread, NULL);
memset(stack, 0xf1, STACK_SIZE);
free(stack);
return 0;
}
Valgrind complains:
==9622== Invalid write of size 1
==9622== at 0x4006149: memset (mac_replace_strmem.c:464)
==9622== by 0x804869D: main (in
/home/A.Salwa/pchelki/user_alloc_stack_problem)
==9622== Address 0x401FED0 is 36,520 bytes inside a block of size
40,000 alloc'd
==9622== at 0x400444E: malloc (vg_replace_malloc.c:149)
==9622== by 0x8048628: main (in
/home/A.Salwa/pchelki/user_alloc_stack_problem)
==9622==
I understand that such behaviour is fine for system-allocated stacks -
right after thread finishes its execution, its stack becomes
inaccessible. But it is user-allocated stack. I'm allowed to do anything
with this memory before calling free(), e.g. reuse it for something else.
Platform info: Linux 2.6.15-1.1830_FC4smp, Valgrind 3.1.1.
I tried to find in Valgrind source the place where client stack is
marked as innaccesible, but without success. Is it a bug ? Should I
enter it into Bugzilla ?
Best regards,
Aleksander Salwa.
|
|
From: Tom H. <to...@co...> - 2006-03-28 11:10:26
|
In message <442...@os...>
Aleksander Salwa <A....@os...> wrote:
> I understand that such behaviour is fine for system-allocated stacks -
> right after thread finishes its execution, its stack becomes
> inaccessible. But it is user-allocated stack. I'm allowed to do
> anything with this memory before calling free(), e.g. reuse it for
> something else.
The problem is that it is very hard to handle this - we have to
engage in guesswork to identify the stack for a new thread as it is.
In fact by using malloc rather than mmap to allocate the stack you
may already have defeated valgrind's heuristic for finding the stack
of a new thread - look at do_clone in m_syswrap/syswrap-x86-linux.c
for the logic it uses to try and find the stack.
> I tried to find in Valgrind source the place where client stack is
> marked as innaccesible, but without success. Is it a bug ? Should I
> enter it into Bugzilla ?
Well it probably is a bug, although quite an obscure one, so yes it
is worth entering it in Bugzilla but I'm not sure whether or not it
will be fixable.
I also can't find the place where it is marked as inaccessible, and
the answer is I suspect that there isn't one.
The point is that as the thread executes whenever the stack is popped
valgrind will mark the popped area as inaccessible - only data above
the current value of the stack pointer is considered accessible. So
the memory is gradually marked inaccessible as routines in the thread
return.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|