emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Post-mortem debugging and abort


From: David Kastrup
Subject: Re: Post-mortem debugging and abort
Date: Fri, 13 Jun 2008 21:48:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Lennart Borgman (gmail)" <address@hidden> writes:

> David Kastrup wrote:
>> Eli Zaretskii <address@hidden> writes:
>>
>>>> From: David Kastrup <address@hidden>
>>>> Date: Fri, 13 Jun 2008 17:02:20 +0200
>>>>
>>>>
>>>> I just wanted to report that the declaration of "abort" in glibc is not
>>>> going to be changed to be more compatible with debugging.
>>>>
>>>> <URL:http://sourceware.org/bugzilla/show_bug.cgi?id=6522> shows my
>>>> report and its resolution.
>>> Sigh.  I concluded a long time ago that it is useless to ask GCC and
>>> glibc developers to cater to debugging needs.  At best, you are
>>> ignored; but more often you are flamed back into silence.
>>
>> I was a bit amused about "stop keeping to reopen".  I reopened once,
>> giving detailed reasons and citing additional manpage data.  When the
>> thing was basically closed without looking at the argument after a month
>> of silence.  So it could not have been all that painful.
>>
>>> I'm sorry that you, David, wasted your effort as well on this.
>
> The discussion of the bug looked like a very difficult thing ;-)
>
> I do not understand the details, but the only thing that looked like a
> response at all was that UD said there was a workaround, "just add gcc
> flag". Just from the non-friendly tone I would expect this to be a
> half lie - half true.
>
> What did he mean and why does it not work as you would like it to?

He means that if you want to have useful post-mortem debugging (namely,
seeing where an assertion went wrong or abort() had been called), you
need to add -fno-crossjumping to the compiler flags.  I found this out
the hard way, by searching for days at the wrong place in Emacs sources.
Naturally, there is no information whatsoever in the gcc or glibc docs
about the importance of this flag for getting usable tracebacks.  There
have been at least two occasions where other Emacs developers have also
spent days of debugging in the wrong place because of this.  I wrote
down in the file etc/DEBUG in Emacs that one should use this flag when
trying to track down the cause of failed assertions.

But of course, people tend not to read such things before being written,
and of course, failed assertions and calls of abort are not exactly
specific to Emacs.

When you don't use the flag, there will tend to be just a single call to
abort compiled into the code and everybody jumps to that call without
bothering to clean up the stack or bothering what happens after the
call.  So at the time the debugger gets to see the stack frame, the
information which abort call in the source code is responsible is lost,
and the stack frame and data on it can only be usefully interpreted when
this information is not lost.

Basically, this will bite you whenever you debug failed assertions and
have not used -O0 for compiling.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]