GNU bug report logs -
#74966
31.0.50; Crash report (using igc on macOS)
Previous Next
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.
Full log
View this message in rfc822 format
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);
}
The out-of-bounds index should come from the function. Can't get at it,
AGM, with the broken LLDB.
HTH a bit.
This bug report was last modified 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.