GNU bug report logs -
#74966
31.0.50; Crash report (using igc on macOS)
Previous Next
Reported by: Sean Devlin <spd <at> toadstyle.org>
Date: Thu, 19 Dec 2024 09:19:02 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Andrea Corallo <acorallo <at> gnu.org>, pipcet <at> protonmail.com,
>> spd <at> toadstyle.org, 74966 <at> debbugs.gnu.org
>> Date: Fri, 20 Dec 2024 09:21:38 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: spd <at> toadstyle.org, 74966 <at> debbugs.gnu.org
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> Date: Fri, 20 Dec 2024 08:30:55 +0100
>> >>
>> >> Gerd Möllmann <gerd.moellmann <at> 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.
This bug report was last modified 161 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.