This is the mail archive of the
mailing list for the GDB project.
Re: Should internal-error default to dumping core?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Fernando Nasser <fnasser at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 13 Jan 2002 15:22:29 -0500
- Subject: Re: Should internal-error default to dumping core?
- References: <3BB88526.firstname.lastname@example.org> <3BB88AE6.F53EDC5@redhat.com> <3BB89072.email@example.com> <3BB893EA.B45050D0@redhat.com>
> Andrew Cagney wrote:
>> Sorry you've lost me here. query() returns false if there is no tty.
>> So ``n'' ``n'' would still be the default. I'll need to change the
>> question so that a ``no'' indicates a core dump.
> That was how I was suggesting it should be, so it is OK with me.
Turns out I'm 180 degrees out here. query() returns true when no TTY.
Consequently I need to reverse first query() not the second.
> At preset an internal-error interaction looks like:
> (gdb) maint internal-error
> /home/scratch/GDB/src/gdb/maint.c:119: gdb-internal-error: internal maintenance
> An internal GDB error was detected. This may make further
> debugging unreliable. Continue this debugging session? (y or n) n
> Create a core file containing the current state of GDB? (y or n) n
> that is the default/no case is to not dump core.
> At present, if GDB encounters an internal error (from say a NULL pointer reference) it doesn't leave any physical evidence around in the form of a core dump. I'm thinking it should. Hence, I'd like to change the second prompt to be one that defaults to a core dump.
> Looking back through the notes it appears that the [my] rationale for the current behavour was somewhat arbitrary.