Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace:implement PTRACE_SEIZE]

[Jan Kratochvil]

Hi Tejun,

On Mon, 16 May 2011 14:42:59 +0200, Tejun Heo wrote:
> I still don't understand why you need to know the order beforehand.
> Wouldn't pending list be enough?  What are you trying to achieve?

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.

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.


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.



Thanks,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/