This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Reporting of "program no longer exists"
- From: Daniel Jacobowitz <drow at false dot org>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 14 Oct 2006 12:39:11 -0400
- Subject: Re: Reporting of "program no longer exists"
- References: <200610142033.16596.ghost@cs.msu.su>
On Sat, Oct 14, 2006 at 08:33:16PM +0400, Vladimir Prus wrote:
>
> Hi,
> suppose a program being debugged got SIGSEGV and the user for GUI frontend
> tries the "next" command. Here's what happens:
>
> (gdb) -exec-next
> ^running
> *stopped,reason="signal-received",signal-name="SIGSEGV".....
> (gdb) -exec-next
> ^running
> Couldn't get registers: No such process.
> ^error,msg="Couldn't get registers: No such process."
This is simply a bug. Try it from the CLI:
(gdb) r
Starting program: /bin/cat
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaac7f352 in __read_nocancel () from /lib/libc.so.6
(gdb) n
Single stepping until exit from function __read_nocancel,
which has no line number information.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
-exec-next ought to report ^running and then that the program has
exited (is that ^exited?). So I'd look at where the error came from.
> (1) How can frontend disable the "next" command? Checking for "SIGSEGV" is
> possible, but it a bit of a hack.
It's wrong. We don't know yet that the SIGSEGV will be fatal. If the
application has a signal handler installed for SIGSEGV, when you
continue the handler will be executed, and life will go on.
--
Daniel Jacobowitz
CodeSourcery