Messages in this thread | | | Date | Sun, 20 Feb 2011 18:48:27 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH |
| |
On 02/20, Denys Vlasenko wrote: > > On Sunday 20 February 2011 10:40, Jan Kratochvil wrote: > > Sure by default GDB does not do anything special, it will respawn (using > > PTRACE_CONT(SIGSTOP)) any SIGSTOP it sees due to the default setting of: > > (gdb) handle SIGSTOP > > Signal Stop Print Pass to program Description > > SIGSTOP Yes Yes Yes Stopped (signal) > > > > Therefore there happens the double SIGSTOP reporting as discussed before: > > (gdb) run > > Starting program: /bin/sleep 1h > > # external kill -STOP <inferior pid> > > Program received signal SIGSTOP, Stopped (signal). > > # State: t (tracing stop) > > (gdb) continue > > Continuing. > > Program received signal SIGSTOP, Stopped (signal). > > # State: t (tracing stop) > > (gdb) continue > > Continuing. > > # State: S (sleeping) > > > > Your proposal is I expect: > > (gdb) run > > Starting program: /bin/sleep 1h > > # external kill -STOP <inferior pid> > > Program received signal SIGSTOP, Stopped (signal). > > # State: t (tracing stop) > > (gdb) continue > > Continuing. > > # State: T (stopped) > > Not exactly. Even after we fix kernel so that it properly preserves > group-stop across ptrace-stops, gdb will still see TWO > waitpid:SIGSTOP events, not one.
Yes, I didn't notice the second report doesn't show SIGSTOP twice. The only important change is
(gdb) continue Continuing. - # State: S (sleeping) + # State: T (stopped)
> I think you can use similar trick in gdb, so that second message says > "Program stopped due to signal SIGSTOP, Stopped (signal)", > not "Program received signal SIGSTOP, Stopped (signal)".
Agreed.
Oleg.
| |