This is the mail archive of the
mailing list for the Archer project.
Re: Q: %Stop && gdb crash
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Oleg Nesterov <oleg at redhat dot com>
- Cc: Roland McGrath <roland at redhat dot com>, archer at sourceware dot org, utrace-devel at redhat dot com
- Date: Tue, 3 Aug 2010 15:36:27 +0200
- Subject: Re: Q: %Stop && gdb crash
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-188.8.131.52-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&
>  2923
> $ cat > SLEEP
> set target-async on
> set non-stop
> target extended-remote :2000
> file /bin/sleep
> attach 2923
> info registers
> $ 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:
> (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
> 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.