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

Previous Next

Package: emacs;

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


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

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

>>> `offset` here should be fixnum that gives the position of this docstring
>>> in the DOC file.  And FUN should be a function for which we found
>>
>> Yes, but the nativecomp code assumes ->doc is an index into a
>> nativecomp'd subr's constant vector.
>
> Aha!
>
>> So we overwrite it with a docfile
>> index, access an out-of-bounds index and crash.
>>
>> I think the best thing to do is to use separate fields for the "offset"
>> doc and the "index" doc; or at least, the second best thing, after
>> removing the entire docfile hack.
>
> I think a much simpler change is to use the sign bit to distinguish indices
> into the constant vector from indices into the DOC file.

And use one's-complement, I assume, to guard against some future weird
nativecomp change resulting in the index -0?  :-)

I really have no strong preference here.

At some point we should remove the DOC hack entirely (pdumper works on
FreeDOS here, now; so with the possible exception of Solaris 10 zones on
x86 Solaris 11, everyone's going to use pdumper and we can use that to
save static data).

But now is not a good time to do so, so we should do whatever affects
the nativecomp code least.  Let's go with the one's complement?

(I'd really like to get Emacs working well in low-memory environments,
such as embedded systems using SRAM rather than DRAM.  I expect most
hardware capable of running Emacs will have an MMU, but it might not
actually be in use).

Pip





This bug report was last modified 130 days ago.

Previous Next


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