bug#15794: Core dump after SIGTERM during GC marking

[Eli Zaretskii]

> Date: Tue, 5 Nov 2013 11:52:09 -0500
> From: Barry OReilly <gundaetiapo@gmail.com>
> Cc: Andreas Schwab <schwab@suse.de>, 15794 <15794@debbugs.gnu.org>
> 
> Since I can't reproduce the original crash, I am trying other means of
> gathering evidence.

I understand.  I'm just saying that you don't necessarily see the same
problem.

> A SIGTERM could be handled at any time right?
> Including as in this artificial reproduction.

Yes, but the effect and the results could be different.

> > But the Lisp backtrace doesn't tell which function of the
> > kill-emacs-hook was running,
> 
> Yes it does. The hook is ede-save-cache. It is one of the two hooks my
> configuration sets up, as I indicated earlier.

Maybe, but I will believe that when I see it explicitly.  Backtraces
from optimized builds are not to be trusted too much.

> > and GC didn't really start doing its job, so it's not exactly the
> > same crash.
> 
> It is after gc_in_progress = 1.

Yes, but the flag is not the issue here.  The issue here is that while
GC runs, it marks Lisp objects, which might make them look invalid to
Lisp code.  In addition, GC can compact strings and other objects, and
if the signal hits at that moment, Lisp code could start working on an
invalid string, or string whose data was moved elsewhere.  But all
this happens when mark_object and its subroutines have really done
some non-trivial job; when you stop GC before they start, all those
problems did not yet materialize.

> Are you trying to argue Emacs cannot possibly enter the SIGTERM
> handler between that and when GC "really starts doing its job"
> (whenever that is)?

No, of course not.

> > And look at the variable 'args', which should be a list. Since this
> > session crashed in GC, it is not safe to print Lisp objects with
> > "pp" and its likes. Instead, you will have to walk the list using
> > "xcar" and "xcdr", display the type of each object in the list using
> > "xtype", and then display the object itself with the appropriate x*
> > command, normally "xsymbol", since the list is constructed from
> > function symbols.
> 
> Can this be done for core dump files?

Yes, the commands I mentioned work for core dumps as well.  They just
manipulate bit masks.

Btw, if you want to see a better backtrace, both in C and in Lisp,
remove or rename the *.elc files of the involved packages.  then Emacs
will run the *.el files in the interpreter, and you will see much more
detail, instead of all those unhelpful exec_byte_code calls that tell
nothing about what is being invoked.