On Friday 08 February 2008 16:17, [EMAIL PROTECTED] wrote: > Author: tom > Date: 2008-02-08 15:17:07 +0000 (Fri, 08 Feb 2008) > New Revision: 7383 > > Log: > Make the clone system call wrappers call VG_(register_stack) to record > the new thread's stack, then make the stack unwinder use that information > to make a better guess at the stack bounds.
Seems like a good plan, perhaps a long-overdue thing to do. Some comments: * 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. * 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)? * 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. J ------------------------------------------------------------------------- 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
