all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: "Lennart Borgman \(gmail\)" <lennart.borgman@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Post-mortem debugging and abort
Date: Fri, 13 Jun 2008 21:48:54 +0200	[thread overview]
Message-ID: <85wsktp13t.fsf@lola.goethe.zz> (raw)
In-Reply-To: <4852AA77.5050305@gmail.com> (Lennart Borgman's message of "Fri,  13 Jun 2008 19:12:23 +0200")

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: David Kastrup <dak@gnu.org>
>>>> 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	other threads:[~2008-06-13 19:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 15:02 Post-mortem debugging and abort David Kastrup
2008-06-13 16:33 ` Eli Zaretskii
2008-06-13 16:48   ` David Kastrup
2008-06-13 17:12     ` Lennart Borgman (gmail)
2008-06-13 19:48       ` David Kastrup [this message]
2008-06-14 15:22         ` Richard M Stallman
2008-06-14 16:08           ` Lennart Borgman (gmail)
2008-06-14 21:20             ` David Kastrup
2008-06-14 23:59               ` Lennart Borgman (gmail)
2008-06-15 17:55             ` Richard M Stallman
2008-06-14  9:37     ` Eli Zaretskii
2008-06-14 21:13       ` David Kastrup
2008-06-14 15:21     ` Richard M Stallman
2008-06-13 17:04   ` Tom Tromey
2008-06-13 19:50     ` David Kastrup
2008-06-14  9:38     ` Eli Zaretskii
2008-06-14 14:11       ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85wsktp13t.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.