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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Apr 12, 2024 at 15:03:03 +0300, Eli Zaretskii wrote:
> > 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.

That won't work for this situation.  The seg fault is happening whilst
loading isearch.el from loadup.el during early building.  I don't have a
running Emacs to probe it with.

> 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.

Yes.  This is the curse of using debuggers, the difficulty of getting
breakpoints placed effectively.  GDB is quite good in this respect,
since you can put a condition on any breakpoint to reduce the false
positives.

> 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).

-- 
Alan Mackenzie (Nuremberg, Germany).