In message <[EMAIL PROTECTED]>
Julian Seward <[EMAIL PROTECTED]> wrote:
> * Would it perhaps be prudent to deregister the stack at thread
> exit? Otherwise, the linked list of stacks grows without bound
> (afaics -- VG_(deregister_stack) is only ever called as a result
> of a client request at the moment). Which clearly isn't too good
> for eg none/tests/manythreads.c.
Probably a good idea, yes. It will probably mean storing the ID value
returned by register_stack in the thread state.
> * In VG_(get_StackTrace), the call to VG_(stack_limits)
> potentially gets a new value for stack_highest_word, and
> that could (?) be higher than the previous value,
> VG_(threads)[tid].client_stack_highest_word (I don't see how,
> but still ..) Maybe more conservative to use the min of
> the values from VG_(threads)[tid].client_stack_highest_word
> and VG_(stack_limits)?
Well really we should probably change client_stack_highest_word when
a stack change happens surely? That was actually my first plan, but
it turned out to be quite hard as VG_(unknown_SP_update) is the place
that detects the change but it is called from generated code without
any easy access to the thread state, and is probably fairly sensitive
to performance issues.
I did consider updating it each time control returned from the client
to valgrind, but that proved non-trivial as well as m_stacks.c is
tracking the concept of the current stack via a global variable.
> * This might give a bit of a performance hit in unwind-
> intensive programs as the stacks list now has to be searched for
> each snapshot. I guess we could mostly ameliorate this by the
> usual trick of incrementally rearranging the list to diffuse
> frequently-requested entries towards the front.
It may be an issue, yes. In fact my original solution to the
problem of stopping the unwinder crashing was to simply ask the
address space manager whether the stack frame we were about to
try and read existed and was readable. That should be completely
bulletproof, but I was worried about the cost as that was done
for every stack entry not just once per unwind.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
