Package: emacs;
Reported by: Sean Devlin <spd <at> toadstyle.org>
Date: Thu, 19 Dec 2024 09:19:02 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: spd <at> toadstyle.org, 74966 <at> debbugs.gnu.org Subject: bug#74966: 31.0.50; Crash report (using igc on macOS) Date: Thu, 19 Dec 2024 14:07:59 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> "Sean Devlin" <spd <at> toadstyle.org> writes:
>>
>>> Hi folks,
>>
>> Hello!
>>
>>> I was using Emacs and encountered a crash.
>>
>> Thanks for reporting it!
>>
>>> I am running on macOS, and I built Emacs from scratch/igc using the
>>> instructions on that branch.
>>>
>>> I didn’t have Emacs running under a debugger, but I do have some crash
>>> information captured by macOS. (See attached.)
>>
>> I'm not entirely sure this is the actual segfault (the
>> EXC_BAD_ACCESS/SIGABRT combination is a little odd):
>>
>> Exception Type: EXC_BAD_ACCESS (SIGABRT)
>> Exception Codes: KERN_INVALID_ADDRESS at 0x595453206f742068 ->
>> 0x000053206f742068 (possible pointer authentication failure)
>> Exception Codes: 0x0000000000000001, 0x595453206f742068
>>
>> That's an ASCII string that we treated as a pointer, it seems?
>>
>> 13 apropos-7c1ecbdf-5d074552.eln 0x103407010
>> F6170726f706f732d736166652d646f63756d656e746174696f6e_apropos_safe_documentation_0
>> + 208
>>
>> Is there any way for you to disassemble this function? At first glance,
>> there's nothing unusual about it (it does use the symbol function, which
>> always confuses me when (function x) was intended but #'x was what I
>> got).
>>
>> I'm not quite sure where the apropos-7c1ecbdf-5d074552.eln file lives on
>> macOS, but I think, if you can find, you can run
>>
>> llvm-objdump -d apropos-7c1ecbdf-5d074552.eln
>>
>> (which will produce a lot of output; we're interested in the section
>> belonging to the
>> F6170726f706f732d736166652d646f63756d656e746174696f6e_apropos_safe_documentation_0
>> section).
>>
>> As this is reproducible, it's probably not a stack marking problem.
>>
>>> At the time, I was trying to use apropos-documentation. I invoked the
>>> command once, entered a string, and hit RET, and it signaled an error. I
>>> tried to do this again and Emacs crashed.
>>>
>>> I hope this is useful. Please let me know if there’s any other
>>> information I can collect.
>>
>> Definitely useful!
>>
>> Thanks!
>>
>> Pip
>
> Building scratch/igc with --enable-checking=all, I get an assertion
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 6.3
> frame #0: 0x00000001004bbd58 bootstrap-emacs`die(msg="0 <= idx && idx < gc_asize (array)", file="./lisp.h", line=2069) at alloc.c:8375:12
>
> frame #1: 0x000000010031bef8 bootstrap-emacs`AREF(array=0x00000001170a5c45, idx=46543) at lisp.h:2069:3
> (lldb) p idx
> (ptrdiff_t) 46543
> (lldb) p array
> Traceback (most recent call last):
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 269, in type_summary_Lisp_Object
> return Lisp_Object(obj).summary()
> ~~~~~~~~~~~^^^^^
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 92, in __init__
> self.init_lisp_types()
> ~~~~~~~~~~~~~~~~~~~~^^
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 113, in init_lisp_types
> vector = self.get_lisp_pointer("struct Lisp_Vector", False)
> TypeError: Lisp_Object.get_lisp_pointer() takes 2 positional arguments but 3 were given
> (Lisp_Object) 0x00000001170a5c45
> (lldb) p gc_asize (array)
> (ptrdiff_t) 48
> (lldb) up
> Traceback (most recent call last):
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 269, in type_summary_Lisp_Object
> return Lisp_Object(obj).summary()
> ~~~~~~~~~~~^^^^^
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 92, in __init__
> self.init_lisp_types()
> ~~~~~~~~~~~~~~~~~~~~^^
> File "/Users/gerd/emacs/savannah/igc/src/../etc/emacs_lldb.py", line 113, in init_lisp_types
> vector = self.get_lisp_pointer("struct Lisp_Vector", False)
> TypeError: Lisp_Object.get_lisp_pointer() takes 2 positional arguments but 3 were given
> frame #2: 0x000000010031c360 bootstrap-emacs`native_function_doc(function=0x0000000108f4e2ad) at comp.c:5580:10
>
> As one can see, my emacs_lldb.py is broken again by something, and so I'm
> half blind. It looks though as if the AREF is here
>
> Lisp_Object
> native_function_doc (Lisp_Object function)
> {
> struct Lisp_Native_Comp_Unit *cu =
> XNATIVE_COMP_UNIT (Fsubr_native_comp_unit (function));
>
> if (NILP (cu->data_fdoc_v))
> cu->data_fdoc_v = load_static_obj (cu, TEXT_FDOC_SYM);
> if (!VECTORP (cu->data_fdoc_v))
> xsignal2 (Qnative_lisp_file_inconsistent, cu->file,
> build_string ("missing documentation vector"));
> return AREF (cu->data_fdoc_v, XSUBR (function)->doc);
> }
That makes sense. I was just looking at the same code and wondering
whether docidx might have been wrong, now I'm wondering why it is wrong
:-)
> The out-of-bounds index should come from the function. Can't get at it,
> AGM, with the broken LLDB.
XSUBR (function)->doc should have been set by comp--register-subr (most
likely), so maybe disassemble the toplevel_run function of the right
.eln file...
> HTH a bit.
It does, thanks!
Pip
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.