Re: abort() to internal_error()

Re: abort() to internal_error()

[Michael Elizabeth Chastain]

> (gdb) pwd
> internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> ....

Fine with me.

If this happens on my workstation, I don't care whether I get
internal_error or a core dump or whatever, I'm going to start debugging
gdb either way.

If this happens on a user's desktop, I prefer the "internal_error"
form, because I'll get "/a/b/c/d/foo.c:47" in the bug report.
I imagine the user either won't care, or will prefer internal_error.

I have a side comment: I've gotten two gdb core dumps in the past month.
Both of them are cycles in the type tree which lead to recursive
death in "maint print symbols".  (One was gdb/15, fixed, and the other
is in gdb/7, not analyzed yet).  So you are still going to get core
dumps even after this change.

But that is a separate issue.

Michael

Re: abort() to internal_error()

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> > (gdb) pwd
> > internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> > ....
> 
> Fine with me.

Just FYI.  The principal was debated and agreed to months (years?) ago.
The only remaining issue (and so minor to really not be anything at all)
is the message.  Even there I don't expect people to disagree -
internal_error() regardless of the message, is infinatly better than
calling abort().

For the curious, the exact message is:

/home/scratch/GDB/src/gdb/maint.c:118: gdb-internal-error: function
calls abort ()

as in:

(gdb) maint internal-error 
/home/scratch/GDB/src/gdb/maint.c:118: gdb-internal-error: internal
maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) y

Create a core file containing the current state of GDB? (y or n) n
(gdb) 

	enjoy,
		Andrew

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16,  3:11pm, Andrew Cagney wrote:

> > This is good enough to go in as is, but I wonder if there is any way
> > can improve the message.  IMO "function calls abort ()" is wrong, or
> > at best misleading, since the function no longer calls abort().
> > Perhaps "failed internal consistancy check" is generic enough without
> > mentioning abort()?
> 
> Thankyou!  I couldn't think of anything sensible.

I've adjusted my script to use "failed internal consistency check"
instead.  (I'll post a patch after the discussion dies down...)

Kevin

Re: abort() to internal_error()

[Andrew Cagney]

"J.T. Conklin" wrote:

> This is good enough to go in as is, but I wonder if there is any way
> can improve the message.  IMO "function calls abort ()" is wrong, or
> at best misleading, since the function no longer calls abort().
> Perhaps "failed internal consistancy check" is generic enough without
> mentioning abort()?

Thankyou!  I couldn't think of anything sensible.

	Andrew

PS: Must not suggest ``Houston, we have a problem''....

Re: abort() to internal_error()

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> KevinB's kindly cooked up a script that will replace all instances of:
Andrew>
Andrew> 	abort ();
Andrew>
Andrew> with
Andrew>
Andrew> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
Andrew>
Andrew> Applying and committing this script will signify the end of a very long
Andrew> campain I've been waging with GDB - to significantly reduce the
Andrew> likelhood that GDB dumps core.

This is good enough to go in as is, but I wonder if there is any way
can improve the message.  IMO "function calls abort ()" is wrong, or
at best misleading, since the function no longer calls abort().
Perhaps "failed internal consistancy check" is generic enough without
mentioning abort()?

Of course, these can, and I suspect will be changed to be specific to
the error condition in the fullness of time.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16, 10:04am, Andrew Cagney wrote:

> KevinB's kindly cooked up a script that will replace all instances of:
> 
> 	abort ();
> 
> with
> 
> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
> 
> Applying and committing this script will signify the end of a very long
> campain I've been waging with GDB - to significantly reduce the
> likelhood that GDB dumps core.
> 
> >From memory, this has been discussed several times before (and is listed
> in the TODO file).  The only problem I can think of is the message. 
> However, if you think about it:
> 
> 	(gdb) pwd
> 	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> 	....
> 
> is still infinatly better than something like
> 
> 	(gdb) pwd
> 	Program received SIGXYZZY, core dumped
> 	$
> 
> so I think is good enough,
> 
> comments?

It should be noted that if the "function calls abort ()" message is
unpalatable for some reason (e.g, lack of specificity), these can be
replaced with something more suitable over time.  In each case, the
choice of a more suitable message will likely depend upon the context,
so I think that Andrew's suggestion is a reasonable first step.  It is
certainly better than what we have now...

Kevin

abort() to internal_error()

[Andrew Cagney]

Hello,

KevinB's kindly cooked up a script that will replace all instances of:

	abort ();

with

	internal_error (__FILE__, __LINE__, "function calls abort ()");

Applying and committing this script will signify the end of a very long
campain I've been waging with GDB - to significantly reduce the
likelhood that GDB dumps core.

From memory, this has been discussed several times before (and is listed
in the TODO file).  The only problem I can think of is the message. 
However, if you think about it:

	(gdb) pwd
	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
	....

is still infinatly better than something like

	(gdb) pwd
	Program received SIGXYZZY, core dumped
	$

so I think is good enough,

comments?

	Andrew