Re: Q: %Stop && gdb crash

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 03 Aug 2010 14:24:34 +0200, Oleg Nesterov wrote:
> On 08/03, Jan Kratochvil wrote:
> > On Wed, 28 Jul 2010 20:17:02 +0200, Oleg Nesterov wrote:
> > Trying it with both /bin/sleep and a threaded testcase and I never got a crash
> > (kernel-2.6.33.6-147.fc13.x86_64 as both host and KVM guest OS).
> 
> To clarify, let me repeat: I never saw such a crash with the real
> gdbserver, but this often happens in my testing.

I am also testing it with your ugdb.c and gdbstub.


On Tue, 03 Aug 2010 15:14:36 +0200, Oleg Nesterov wrote:
> On 08/03, Oleg Nesterov wrote:
> >
> > So I assumed it is always safe to resend the notification unless gdb already
> > sent vStopped. Since it is not clear to me when it makes sense to resend it,
> > currently gdbstub does re-send every time /proc/ugdb reports the new event
> > (T00 in this case). I agree this is not optimal, but this looks correct to me.
> 
> I'll change gdbstub to never resend the notification to avoid the problem.

Yes, I has been now just writing you such reply.


> But probably gdb should be fixed anyway.

There are so many serious bugs in GDB affecting regular GDB usage...


> To avoid the unnecessary details, consider the oversimplified example,
> 
> 	$ sleep 10000&
> 	[1] 2923
> 
> 	$ cat > SLEEP
> 	set target-async on
> 	set non-stop
> 	target extended-remote :2000
> 	file /bin/sleep
> 	attach 2923
> 	info registers
> 	detach
> 	^D
> 
> 	$ gdb <SLEEP
> 	GNU gdb (GDB) 7.1
> 	Copyright (C) 2010 Free Software Foundation, Inc.
> 	License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> 	This is free software: you are free to change and redistribute it.
> 	There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> 	and "show warranty" for details.
> 	This GDB was configured as "x86_64-unknown-linux-gnu".
> 	For bug reporting instructions, please see:
> 	<http://www.gnu.org/software/gdb/bugs/>.
> 	(gdb) (gdb) (gdb) Remote debugging using :2000
> 	(gdb) Reading symbols from /bin/sleep...(no debugging symbols found)...done.
> 	(gdb) Attached to process 2923
> 	[New Thread 2923.2923]
> 	Target is executing.
> 	(gdb) Detached from remote process 2923.
> 	(gdb) quit
> 
> And yes, gdb ignores %Stop and just detaches. But this is because
> of another issue (which looks like a minor gdb bug to me), note the
> 
> 	"Target is executing."
> 
> above. This is the reply to "info registers". Why? OK, yes, it is
> executing.

Yes.


> Then send vCont:t ? "attach PID" means attach and stop it, no?

But it is not yet stopped that time.


> Can't resist, I spent a lot of time trying to understand what is wrong.

Nothing, you should wait till GDB reports the inferior has stopped.  It is
easy/normal in the GDB testsuite and by FE (Front Ends).  I understand it is
not convenient from -ex or -x argument.  There could be probably some
async-only command besides `interrupts', also some `wait-till-stopped'.


> I tried to achieve the same results with /proc/ugdb doing
> "$ gdb < BATCH_FILE" with the same commands.

Maybe you can write a new *.exp testcase for such testing.


Thanks,
Jan