|
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/
|