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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: pipcet <at> gmail.com, 47067 <at> debbugs.gnu.org
Subject: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c
Date: Sun, 14 Mar 2021 09:48:49 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: pipcet <at> gmail.com, 47067 <at> debbugs.gnu.org
> Date: Sun, 14 Mar 2021 07:31:14 +0000
> 
> >> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47067#98>
> >
> > Shouldn't that bump the ABI number as well?
> 
> Right good point I think it should.
> 
> Anyway thinking about: this should be good for a quick test maybe
> removing (or renaming) the discussed .eln.  But if it proves this to be
> the bug you'll have to rebuild from scratch to have a reliable system
> anyway , as the ABI number will not cover us for the native code that
> was already dumped with the image.

Sorry, I don't understand: what is the procedure for testing this
patch?

I thought I should do this, in the order specified:

  . apply the patch
  . increase the ABI version
  . rebuild Emacs
  . natively-compile all the preloaded Lisp files, then redump Emacs
  . visit a C file and let Emacs native-compile all the cc-*.el files
  . restart Emacs and try reproducing the crash

Are there any shortcuts that don't run the risk of invalidating the
test results?  Since we are changing something so basic in how Lisp is
native-compiled, and since non-local exits are so common on our
sources, can I really do less than the above and be sure the solution
works reliably?

Previous Next

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