[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gdb doesn't print Lisp backtrace in some circumstances.
From: |
Gerd Möllmann |
Subject: |
Re: gdb doesn't print Lisp backtrace in some circumstances. |
Date: |
Fri, 12 Apr 2024 16:48:24 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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. 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 think it's easier to go through the specbinding stack
(current_thread->m_specdl). For LLDB, I did that in the xbacktrace
function in etc/emacs_lldb.py.
Re: gdb doesn't print Lisp backtrace in some circumstances.,
Gerd Möllmann <=