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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Apr 12, 2024 at 16:24:53 +0300, Eli Zaretskii wrote:
> > Date: Fri, 12 Apr 2024 13:18:15 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> I don't see why can't you have a running Emacs.  You just need to run
> temacs under GDB instead of emacs, and you need to run the exact
> command that crashes under GDB.  To see what command crashes, run
> "make V=1", to force make to display every command it runs in its
> entirety.

Maybe I'll try that.  What I eventually did yesterday was to code in a
limit of 150 to the length of the last argument in Fapply, signalling an
error when it was higher.  Even this (Lisp) backtrace is difficult to
decypher.

The backtrace I got is a mess.  The problem has a lot to do with generic
functions, and cl-generic.el is as good as entirely undocumented.
Didn't we have somebody volunteering to fix this some months ago?  Has
anything come of that, yet?

-- 
Alan Mackenzie (Nuremberg, Germany).