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

From: Gerd Möllmann <[email-masked]>
Date: Sat, 21 Dec 2024 09:07:40 +0100

Eli Zaretskii <[email-masked]> writes:

>> From: Gerd Möllmann <[email-masked]>
>> Cc: Pip Cet <[email-masked]>,  [email-masked],  [email-masked],
>>   [email-masked],  [email-masked]
>> Date: Sat, 21 Dec 2024 08:08:40 +0100
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> 
>> >> I agree that the docfile hack in general is very hairy territory.  It
>> >> might be safer to simply accept the wrong docstrings for now, and Gerd's
>> >> patch does that, IIUC.  Can we just apply that for now and add a FIXME?
>> >
>> > Maybe, but I'd like first to understand better the "wrong docstrings"
>> > situations.
>> 
>> Maybe I can explain this. The current error's cause is that nativecomp
>> currently (wrongly) assumes that it never needs an offset into DOC, so
>> it reused Lisp_Subr::doc for its own purposes, namely as an index into a
>> vector contained in an .eln file. The doc string of a function is found
>> at that index.
>> 
>> Pip's patch changes nativecomp code stores the said index from above in
>> a new Lisp_Subr::doc_index, and makes it possible to fix the wrong
>> assumption from above, Nativecomp of course has to check which of the
>> now two members it has to use, which Pip does.
>> 
>> Renaming Lisp_Subr::doc to Lisp_Object::doc_offset is a nice extra, IMO,
>> because it makes it clearer what the member contains.
>
> OK, thanks.  I'd like Andrea to chime in first and see if he can fix
> this on the nativecomp side.

Ok.

> Also, Stefan said something about using a Lisp_Object for the value?

Haven't seen or registered that, so I better leave that to Stefan to
explain.

>
> And finally, does what you wrote explain the "wrong docstrings"
> situation, or does it only explain the crash you saw?  If the former,
> I'm afraid I'm still missing something, because I don't understand how
> this could cause a wrong docstring to be used.

I understood that as "if we avoid setting Lisp_Subr::doc for native
compiled functions, then we'll use "SKIP:..." as the doc string (e.g.
for x-file-dialog), which is the wrong docstring." That would be the
the little patch I posted first.