|
From: Josef W. <Jos...@gm...> - 2005-05-30 22:03:01
|
Hi, I have a question on Valgrind scheduling (I have a bug here in my tool): as callgrind has "shadow" call stacks for each thread, it always needs to know which thread currently is running. Usually, this is no problem with VG_(track_thread_run). I also track signal handlers. And these can switch the running thread. VG_(track_thread_run) is not called directly after a signal handlers return. So the question is, what thread is resumed when a signal handler returns? Do I have to track this myself? And if, how to do this? Can there be a thread switch while a signal handler is running? Thanks for any answer; I somehow can see the solution from Valgrinds source. Josef |
|
From: Jeremy F. <je...@go...> - 2005-05-31 22:16:34
|
Josef Weidendorfer wrote:
>I have a question on Valgrind scheduling (I have a bug here in my tool): as
>callgrind has "shadow" call stacks for each thread, it always needs to know
>which thread currently is running. Usually, this is no problem with
>VG_(track_thread_run).
>
>I also track signal handlers. And these can switch the running thread.
>VG_(track_thread_run) is not called directly after a signal handlers return.
>So the question is, what thread is resumed when a signal handler returns? Do
>I have to track this myself? And if, how to do this?
>Can there be a thread switch while a signal handler is running?
>
>
In general, signals do not explicitly cause thread context switches. A
thread may become runnable because it received a signal, but it is no
different from any other reason a thread may become runnable (like a
syscall unblocking). Likewise, returning from a signal doesn't
explicitly cause a thread context switch.
A signal handler isn't special in any way, so there's always a chance
you can get a context switch in a signal handler.
What problem are you seeing?
J
|
|
From: Josef W. <Jos...@gm...> - 2005-06-01 14:59:48
|
On Wednesday 01 June 2005 00:16, you wrote: > Josef Weidendorfer wrote: > In general, signals do not explicitly cause thread context switches. A > thread may become runnable because it received a signal, but it is no > different from any other reason a thread may become runnable (like a > syscall unblocking). Likewise, returning from a signal doesn't > explicitly cause a thread context switch. > > A signal handler isn't special in any way, so there's always a chance > you can get a context switch in a signal handler. > > What problem are you seeing? In my tool, I have global pointers to per-thread data structures. These pointers need to be updated on a thread context switch. I track context switches via callbacks SK_(thread_run)(ThreadId tid) and SK_(pre_deliver_signal)(ThreadId tid, ...) for switches before entering a signal handler. Now I have a bug report with an assertion because my data structures are getting corrupted. Looking at it, I see that there is an signal handler switching thread via SK_(pre_deliver_signal)(ThreadId tid, ...), and on returning, the previous running thread seems to be resumed, but I do not get any callback (e.g. via thread_run) that there is a thread context switch after the signal handler. If I restore the thread context which has executed before the signal handler, the assertion is gone for a small test case, but not for a more complex one. So this is no general solution if there can be context switches in a signal handler. The thing I need is a SK_(thread_run) callback after the signal handler if thread contexts are switching, and this is missing currently. I.e. it would be good to be able to track the current TID always via callbacks. But I need a solution which works with current VG releases. Perhaps setting the tracked TID to 0 after a signal handler is finished would be a possibility. Then, before any per-thread structure is accessed, the actual TID is looked up lazily via VG_(get_current_or_recent_tid)(), and the global pointers are corrected accordingly. Or accessing all per-thread data always via indirection, calling VG_(get_current_or_recent_tid)() everytime. I assume this will give some performance hit. Josef |
|
From: Jeremy F. <je...@go...> - 2005-06-01 22:07:34
|
Josef Weidendorfer wrote:
>Now I have a bug report with an assertion because my data structures are
>getting corrupted. Looking at it, I see that there is an signal handler
>switching thread via SK_(pre_deliver_signal)(ThreadId tid, ...), and on
>returning, the previous running thread seems to be resumed, but I do not get
>any callback (e.g. via thread_run) that there is a thread context switch
>after the signal handler.
>
>
Yep, that looks like a bug. There should be a call to
VG_(tm_thread_switchto)(tid); in vg_async_signalhandler(), though
perhaps VG_(set_running)() should always call it.
>Or accessing all per-thread data always via indirection, calling
>VG_(get_current_or_recent_tid)() everytime. I assume this will give some
>performance hit.
>
>
That will work, and its how other tools keep track of per-thread info.
It isn't particularly slow, so I would try it and see.
J
|