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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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);
  }

The out-of-bounds index should come from the function. Can't get at it,
AGM, with the broken LLDB.

HTH a bit.