|
From: Josef W. <Jos...@gm...> - 2005-08-03 23:40:07
|
Hi, I'm just examining a strange signal handling bug with callgrind (and VG 2.4.1), and I have the executable to reproduce this error. As callgrind wants the call graph of signal handlers in separate contexts, I track pre/post-signal hooks and do the call tracking accordingly. Now I got a failed assertion at program end that one thread is inside a signal handler context, but %esp is at a position were it should have already left the handler. After some examination, I found the place were the thread enters the signal handler, and in there, it does a longjump(), and this longjmp() surpasses the signal handler stack frame by simply resetting %esp. And obviously VG does not notice this either, as there is no post-signal event generated at all. Is this some obscore VG bug, or is it expected that pre/post-signal hooks for VG tools are not called reliable (e.g. when a signal handler transfers control via longjmp), or is it correct that a thread which does a longjmp() in a signal handler to regular code is still running in a signal handler context? I suppose not as the signal frame was surpassed/discarded? If other tools similarly expect that these hooks are called reliable, there is probably a bug in these tools, too. The signal handler doing the longjmp() is in libpthread.so, so I suppose there was no bug when we still had our own pthread implementation. But on there other hand, longjmp's from signal handlers seem to be quite common, if it is to be found in standard libpthread. So VG should handle this... Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-08-04 14:56:16
|
On Thu, 4 Aug 2005, Josef Weidendorfer wrote:
> As callgrind wants the call graph of signal handlers in separate contexts, I
> track pre/post-signal hooks and do the call tracking accordingly.
> ...
> Is this some obscore VG bug, or is it expected that pre/post-signal hooks for
> VG tools are not called reliable (e.g. when a signal handler transfers
> control via longjmp)
It's expected. include/pub_tool_tooliface.h says:
/* Called after a signal is delivered. Nb: unfortunately, if the signal
handler longjmps, this won't be called. */
void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo));
It's always been like this, I believe.
I don't know if this is much help to you, though...
N
|
|
From: Josef W. <Jos...@gm...> - 2005-08-04 15:22:29
|
On Thursday 04 August 2005 16:56, Nicholas Nethercote wrote: > On Thu, 4 Aug 2005, Josef Weidendorfer wrote: > > As callgrind wants the call graph of signal handlers in separate > > contexts, I track pre/post-signal hooks and do the call tracking > > accordingly. ... > > Is this some obscore VG bug, or is it expected that pre/post-signal hooks > > for VG tools are not called reliable (e.g. when a signal handler > > transfers control via longjmp) > > It's expected. include/pub_tool_tooliface.h says: > > /* Called after a signal is delivered. Nb: unfortunately, if the signal > handler longjmps, this won't be called. */ > void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo)); Oh. I should check for comments in the header files more often. It was new to me that you can exit a signal handler via longjmp. The fix was quite easy. After every BB, I try to synchronize my shadow call stack with the real %esp by unwinding as needed. Now in the unwinding, I check if I pass a signal handler border, and switch the context if needed. Thanks for the hint. Josef > > It's always been like this, I believe. > > I don't know if this is much help to you, though... > > N > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |