GNU bug report logs - #74966
31.0.50; Crash report (using igc on macOS)

Previous Next

Full log

Message #149 received at 74966 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: spd <at> toadstyle.org, Eli Zaretskii <eliz <at> gnu.org>, acorallo <at> gnu.org,
 monnier <at> iro.umontreal.ca, 74966 <at> debbugs.gnu.org
Subject: Re: bug#74966: 31.0.50; Crash report (using igc on macOS)
Date: Sat, 21 Dec 2024 11:31:25 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> 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.

Using an integer would reduce the work for igc a bit. Not that it
matters much.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.