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

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  pipcet@protonmail.com,
>>   spd@toadstyle.org,  74966@debbugs.gnu.org
>> Date: Fri, 20 Dec 2024 09:21:38 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Cc: spd@toadstyle.org, 74966@debbugs.gnu.org
>> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> >> Date: Fri, 20 Dec 2024 08:30:55 +0100
>> >> 
>> >> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> >> 
>> >> > I think I'll read the code a bit now.
>> >> 
>> >> BTW, does C-h f x-file-dialog work on platforms != macOS?
>> >
>> > In what version of Emacs? and with or without native compilation?
>> 
>> master with native compilation, if possible with --enable-checking.
>> 
>> >
>> > It works here as follows:
>> >
>> >   . On MS-Windows:
>> >     - emacs 31 without native compilation
>> >     - emacs 30 with and without native compilation
>> >   . On GNU/Linux:
>> >     - emacs 31 with and without native compilation
>> >     - emacs 30 with and without native compilation
>> >
>> >> It aborts here for the same reason.
>> >> 
>> >> And I'm asking myself now why the heck it lands in native_function_doc in
>> >> the first place. Isn't x-file-dialog a C function everywhere?
>> >
>> > It is a C function, yes.
>> 
>> My current theory is that one needs to C-h f a function with a doc
>> string lie this one:
>> 
>> (defun x-file-dialog (prompt dir &optional default-filename
>>                              mustmatch only-dir-p)
>>   "SKIP: real doc in xfns.c."
>>   (ns-read-file-name prompt dir mustmatch default-filename only-dir-p))
>> 
>> And the function must be native-comp-function-p.
>> 
>> I can't see so far how/where such "redirections" are handled.
>
> AFAIR, the doc string is in etc/DOC, and is collected by
> lib-src/make-docfile.  That program scans the C source according to
> what src/Makefile tells is (see the $(etc)/DOC rule there), so it
> doesn't care whether xfns.c is or isn't compiled into the binary.

Yes, that matches what I remember from the old times.

> But we had many changes lately in how etc/DOC is handled, and maybe my
> memory is no long accurate.  So I added Stefan to this discussion, who
> made at least some of those DOC-related changes.

Maybe the problem is in store_doc_string (doc.c:469 here), not sure.
That function does

  if (SUBRP (fun))
    XSUBR (fun)->doc = offset;

without checking if it's a native compiled function. That does look
like a place where an invalid offset could land in the subr.

I have no idea what's the right thing to do to fix this. Just not doing
anything for native compiled function certainly isn't right.