Re: gdb doesn't print Lisp backtrace in some circumstances.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 12 Apr 2024 11:29:29 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > But you can reproduce the Lisp backtrace manually (albeit tediously,
> > by going over all the calls to Ffuncall, eval_sub and suchlikes, and
> > displaying their arg[0].  If it's a symbol, typing xsymbol should show
> > you the Lisp function being called.  If it is not a symbol, you could
> > use xcar/xcdr etc., but that is much more tedious, and I usually give
> > up on those frames in the stack.
> 
> I spent a large part of yesterday on this dump.  It ends up with a call
> (apply apply ...) which goes into an infinite recursion with the number
> of arguments increasing by 1 at each stage.  I've found the point in the
> backtrace where the recursion starts, but it's tedious indeed getting
> information out of it.  I think I'll have to, though, since I can't see
> any other way of debugging this at the moment.

One way of avoiding all this tedious manual work is to try to catch
the problem with a breakpoint in a running Emacs, not in a core dump.
You need to be creative and most probably invest a lot of efforts in
trial-and-error to come up with a breakpoint place and condition that
on one hand doesn't cause it to trigger too often for false positives,
and OTOH doesn't miss the real problem.

An easier way is to run Emacs under GDB to begin with, and do what you
need to do when it catches the segfault, before dumping core.  At that
point, you still have a running Emacs, and can call functions inside
it, albeit less safely (because when Emacs is crashing, its Lisp
machine could be utterly confused or messed up).