bug#74966: 31.0.50; Crash report (using igc on macOS)

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> "Sean Devlin" <spd@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