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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Apr 12, 2024 at 14:11:04 +0300, Eli Zaretskii wrote:
> > Date: Fri, 12 Apr 2024 10:31:53 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Yesterday I got a core dump from a segmentation fault in Emacs (my
> > development version, not master).  I loaded this into gdb inside Emacs
> > to have a look at it.

> > The backtrace command output the C data as it should, but on coming to
> > the Lisp backtrace gave an error message about there needing to be a
> > process running to "do this".  (I don't have the exact message any
> > more.)  It would seem these fancy Lisp facilities only work when the
> > process that produced them is still running.

> Yes, because they call functions inside Emacs to format Lisp objects.

> > All the information required to produce this Lisp backtrace is present
> > in the core dump.  Would it be possible, perhaps, to modify our .gdbinit
> > to use the running Emacs to process the core dump, or something like
> > that?

> I don't think so, no.

That's what I feared.

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

-- 
Alan Mackenzie (Nuremberg, Germany).