Wishlist: declarations suitable for post mortem debugging

Paul Pluzhnikov ppluzhnikov@google.com
Thu Apr 26 13:08:00 GMT 2012


David,

This is probably best discussed on libc-alpha (CC'd).

Providing a link to previous discussion, bugzilla PR, etc. might help.

Providing an actual example where you wasted days on "fake" stack
trace may also help.

On Thu, Apr 26, 2012 at 2:49 AM, David Kastrup <dak@gnu.org> wrote:
>
> We have attributes like
>
> /* This prints an "Assertion failed" message and aborts.  */
> extern void __assert_fail (__const char *__assertion, __const char *__file,
>                           unsigned int __line, __const char *__function)
>     __THROW __attribute__ ((__noreturn__));
>
> in assert.h and
>
> extern void abort (void) __THROW __attribute__ ((__noreturn__));
>
> in stdlib.h.  These functions, in contrast to exit, have a side effect
> of dumping core as a regular effect of their execution.  The purpose is
> to enable post-mortem debugging.
>
> The attribute __noreturn__ directly conflicts with that purpose since it
> tells the compiler it may trash the stack when calling the function, not
> requiring any useful information to be retained on the stack.  In
> particular, those functions may be _jumped_ to instead of called, or an
> existing call to these functions in an unrelated part of source may get
> recycled by jumping to it.
>
> As a result, backtraces from the core dump are quite unreliable.  I
> have, on several occasions, spent days of futile debugging on backtraces
> that did not correspond with reality.
>
> So I would strongly suggest that functions that are _explicitly_
> intended to dump core don't get marked as "__noreturn__".  This seems
> like a rather straightforward way to stop the compiler from making those
> core dumps much less useful than they should be.  While it might be
> conceivable to invent a special __coredump__ flag to make sure that the
> generated code around such a call (including local variables) fully and
> uniquely corresponds with the available debug information, that seems
> like a quite more complex endeavor.
>
> I did suggest removing __noreturn__ attributes on core dumping functions
> some years ago, but was chased away without use of minced words since my
> request was considered incompatible with the holy grail of optimization,
> and talking about debugging should only be allowed on entirely
> unoptimized code.  The kind of arguments and name-calling used for
> putting a stop to my request were nothing I would have considered
> compelling on technical grounds, so I am reraising that request in light
> of assurances of a changed overall climate in glibc development.  I am
> quoting a passage from Emacs "DEBUG" file that resulted from the
> non-acceptance of my proposal.  I may add that _several_ Emacs
> developers were afflicted by this problem and wasted several days on
> different bugs each, so it is not academical.
>
>    ** When you are trying to analyze failed assertions, it will be
>    essential to compile Emacs either completely without optimizations or
>    at least (when using GCC) with the -fno-crossjumping option.  Failure
>    to do so may make the compiler recycle the same abort call for all
>    assertions in a given function, rendering the stack backtrace useless
>    for identifying the specific failed assertion.

Yes, but assertions *also* print file/line info, and appears that
file/line should be quite sufficient for identifying the specific
assertion that failed.

>
> Of course, it is not just glibc that is concerned here since GCC itself
> has built-in definitions for some of those functions.  But those are
> intended to follow the glibc in spirit, I should think, so I think that
> one should start here concerning this issue.
>
> Thanks for caring
>
> --
> David Kastrup



-- 
Paul Pluzhnikov



More information about the Libc-help mailing list