Re: crash: x_error_quitter

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>     >       Which means that the traceback is likely completely
>     >     wrong, and local variables, in particular those that have been stored
>     >     in registers, are also completely unusable.
>     >
>     > I think that is incorrect.  The frames on the stack give all the
>     > necessary information, once (x-synchronize t) has been used.
>
>     It would be helpful if you actually quoted the _relevant_ parts of
>     what you are commenting on.
>
> I think did so.
>
>     x_connection_closed is declared NO_RETURN, so gcc will not bother
>     about leaving the stack in a recognizable state when calling it.
>     Whether or not that affects the calls of x_error_quitter may depend on
>     whether gcc consequently figures out it being NO_RETURN, too.  With
>     gcc's current optimization strategies, that is quite plausible.
>
> The crucial information for debugging this problem is which X
> library functions were called, and their arguments, and where the
> call came from.  I don't think that calling a NO_RETURN subroutine
> will spoil outer-level stack frames like this.  I think they will be
> visible.

The stack frames will usually not get affected.  But the return
address might be completely wrong, and that will affect gdb's idea of
what function the stack frame belongs to, and what variables are
stored in what registers at that point of time.

That's because gcc will, instead of calling a NO_RETURN function, just
jump to an arbitrary point elsewhere where it is called.  So at least
the information about the immediate caller of a NO_RETURN function
(one that gcc knows as being NO_RETURN, not necessarily one explictly
declared as such) is not fit for debugging.

Personally, I think the tradeoff of saving a few bytes for being able
to use a (potentially conditional) short jump instead of a call is not
worth the cost in savings unless one specified an option
--fsavememory=lethallyaggressive or so, but one would have to bring
this issue up with the gcc developers.

> But if there is a problem, then we should get rid of NO_RETURN for
> this function, because there is no point in optimizing it.

I think that if we are compiling with -g, we should also enable the
-fno-crossjumping option.  Drawback is that this will cause slightly
different code to be produced.  Advantage is that it makes actually
usable stack frames for post-mortem analysis much more likely.

-- 
David Kastrup