GNU bug report logs - #47067
28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Pip Cet <pipcet <at> gmail.com>, 47067 <at> debbugs.gnu.org
Subject: Re: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling
 through dispnew.c
Date: Sat, 13 Mar 2021 20:53:00 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Pip Cet <pipcet <at> gmail.com>
>> Date: Sat, 13 Mar 2021 16:32:50 +0000
>> Cc: Andrea Corallo <akrl <at> sdf.org>, 47067 <at> debbugs.gnu.org
>> 
>> > > > > So EDI is bunk at this point. Can you go back a bit further to where
>> > > > > it's initialized?
>> > > >
>> > > > Sorry, I don't understand: I gave you the disassembly of 512 bytes
>> > > > before, isn't that enough to see where EDI is assigned the value?  Or
>> > > > what do you mean by "go back"?
>> > >
>> > > It's not enough, no. we're looking for an insn of the form mov XXX,
>> > > %edi or lea XXX, %edi, or anything like that.
>> >
>> > I went back 4KB, and the only two instructions that write into EDI are
>> 
>> It's a long function, that might not have been enough.
>
> But since I found those two, everything before that is irrelevant,
> right?
>
>> > > I'm suspicious because EDI is a register variable that is clobbered
>> > > somehow right after a setjmp returned. Which setjmp implementation are
>> > > you using?
>> >
>> > Not sure how to answer that.  AFAIK, it's a setjmp from the MS runtime.
>> 
>> So not some mingw wrapper for it?
>
> No, not that I could see.
>
>> I just checked the only "mingw"-like sources I could find, and they
>> don't appear to use the frame pointer argument properly...
>
> Why is this suddenly relevant when native compilation is involved?
>
>> > > Is it possible that you're on Windows, but unlike other Windows
>> > > setjmps, it's unsafe to call your setjmp through a function pointer?
>> >
>> > How do I tell?
>> 
>> Well, you could just apply this untested patch, fix any obvious
>> compile errors I might not have spotted, and try to reproduce it. I'm
>> not currently on a Windows (or x86) machine, so it's a bit hard for me
>> to test...
>
> I'd like this investigation to be less of a blind search, sorry.  can
> you tell what to check or look at to see if this is relevant?

One confirmation that the issue is the one suggested by Pip would be
running the test we added for this with like:

$ ./src/emacs -batch -l test/src/comp-tests.el --eval '(ert-run-tests-batch-and-exit "46824-1")'

If the test-case fails it would be a clear marker, if it doesn't the
issue might still the be the suggested one but the different architecture
might play a role here making the test-case ineffective.

Thanks

  Andtea

PS Eli, even better would be to run all tests in comp-tests.el as a
quick sanity check to verify that all is okay.

Previous Next

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