This is the mail archive of the
mailing list for the Archer project.
Re: [patch] Re: [BUG] gdb: quit hangs after step into signal handler
- From: Roland McGrath <roland at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Oleg Nesterov <oleg at redhat dot com>, archer at sourceware dot org
- Date: Wed, 23 Feb 2011 12:27:10 -0800 (PST)
- Subject: Re: [patch] Re: [BUG] gdb: quit hangs after step into signal handler
- References: <20100920211715.GA10574@redhat.com><20100921235356.BB1F340614@magilla.sf.frob.com><20110223202454.GA4687@host1.dyn.jankratochvil.net>
> On Wed, 22 Sep 2010 01:53:56 +0200, Roland McGrath wrote:
> > Even if you were paranoid about some old kernel where PTRACE_KILL might work
> > better (dubious if there are any such, but that's why it's paranoia), you
> > could do this before PTRACE_KILL and it should certainly be fine everywhere.
> Problem is the inferior will start running after PTRACE_KILL. Current GDB:
> Quit anyway? (y or n) y
> <hang by sleep (600);>
> read(0, "y\n", 1024) = 2
> ptrace(PTRACE_KILL, 32336, 0, 0) = 0
> Before kill (SIGKILL) gets applied the code may do something unexpected.
> Why do you consider SIGKILL first, PTRACE_KILL second as worse?
What I recommended is kill/SIGKILL first, PTRACE_KILL second.
That's not worse than anything else.