[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gdb doesn't print Lisp backtrace in some circumstances.
From: |
Alan Mackenzie |
Subject: |
Re: gdb doesn't print Lisp backtrace in some circumstances. |
Date: |
Sat, 13 Apr 2024 10:07:09 +0000 |
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).
Re: gdb doesn't print Lisp backtrace in some circumstances., Gerd Möllmann, 2024/04/12