On Fri, Feb 22, 2008 at 3:37 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
> Yes. I'm only saying that track_{start,stop}_client_code look correct
> to me, and so the problem is more likely to be elsewhere, perhaps:
>
> VG_(get_running_tid)() produces wrong results, under some circumstances,
>
> or
> the assertion that VG_(get_running_tid)() and track_{start,stop}_client_code
> agree is not always valid, for some subtle reason.
>
> I am a bit unclear about the precise semantics of VG_(get_running_tid)
> (was it ever specified, exactly? I don't know). That probably doesn't
> help. A first step might be to specify exactly the behaviour of this fn.
At least for the exp-drd/tests/sigalrm.c regression test, the value of
VG_(get_running_tid)() is always correct.
track_{start,stop}_client_code is invoked around all client code, but
not around all client memory accesses. There is a subtle difference:
e.g. before the code of a signal handler is executed, a signal context
is set up. track_start_client_code is invoked after the signal context
is set up and before the code of the signal handler is executed. This
is what causes the mismatch in case of signal handlers.
Bart.
-------------------------------------------------------------------------
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
