Messages in this thread | | | Date | Mon, 16 May 2011 15:51:41 +0200 | From | Tejun Heo <> | Subject | Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace: implement PTRACE_SEIZE] |
| |
Hello, Jan.
On Mon, May 16, 2011 at 03:03:39PM +0200, Jan Kratochvil wrote: > If you check the GDB debugging session transcript I gave GDB stopped in > a moment when all the threads already returned from tkill()s sending SIGUSR1s > and SIGUSR2.
Yeap.
> All threads are stopped, user is investigating the situation. And GDB tells > the user (only) SIGUSR1 was delivered. The user has no chance to find out > SIGUSR2 is already pending / to be delivered. This is one of the many reasons > why debugging various racy cases is a nightmare. > > I was trying to suggest some ways how to give user the complete overview of > the debuggee situation - where both SIGUSR1 and SIGUSR2 would be reported on > the first stop. > > You are right GDB could examine SigCgt, SigBlk (not sure if others) and report > those signals. Maybe it is right that way and we can forget about it.
Yes, I think this is the correct way to deal with it. Multiple signals can be pending and/or blocked but a single thread can only deliver a single signal at any given time, which may involve userland execution. Parallel delivery simply isn't defined, so I think what you want here is the list of pending signals, not deliveries, and then consulting the pending mask is the obvious thing to do.
> There is (was) a larger problem of signals reordering which I fixed in > [patch 3/4]#3 linux-nat: Do not respawn signals > http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html > but that mess you should have fixed by PTRACE_INTERRUPT which no longer > interacts with signals. But it gave me the idea of another situation above > where the debugger may want to know all the currently pending signals at once.
Yeap, I agree that it would be nice if gdb informs the user of the pending signals when it stops for signal delivery.
Thank you.
-- tejun
| |