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

[Pip Cet]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>>> 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.

Absolutely!

>> 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.

I suggested doing so, I'm not aware of either Stefan suggesting it (as
both of them feature prominently in the git blame for doc.c, I'm not
sure which Stefan was meant).

>> 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.

That's what I meant, yes.  I'm not aware of any other wrong docstrings:
fixing the crash would leave the "SKIP:" docstrings in, to fix them we
need a bit to distinguishing doc-is-vector-index from doc-is-DOC-offset.
One handy source for that bit is the tag bits of a Lisp_Object.

A nice side effect would be that we could change docstrings to something
that we can't find in DOC, and possibly make the fixnum-as-a-DOC-offset
thing optional if we decide it's no longer generally useful.

(Maybe someone would even like to experiment with storing something other
than a string or fixnum in it.)

I'm not certain which approach would be safer: a Lisp_Object is unlikely to
be mistakenly used as an integer value, and the Lisp_Object would remove
uncertainty about whether doc_offset or doc_index "wins", but it would
also mean changes in a few more places, particularly the nativecomp
code.

Pip