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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 47067 <at> debbugs.gnu.org
Subject: Re: 28.0.50; [feature/native-comp] Crash while scrolling through
 dispnew.c
Date: Sat, 13 Mar 2021 10:34:06 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 47067 <at> debbugs.gnu.org
> Date: Fri, 12 Mar 2021 20:10:27 +0000
> 
> >> > Just evaluating c-beginning-of-statement-1 doesn't help.  But if I
> >> > load cc-engine.el, then the crash goes away.
> >> 
> >> Okay, then probably is one of the other four c-* functions we see in the
> >> backtrace.
> >
> > Yes, but how to determine which one?
> 
> Given they are 4 one could go evaluating these one by one, if they were
> more bisection would have been the best strategy.  Yeah that's not the
> most fun...

I was wrong: it _is_ c-beginning-of-statement-1, after all.  It's just
that the procedure I followed to evaluate is was wrong.  AFAIU now, it
should be: first load-library cc-engine (which loads the .eln file),
then evaluate the function's definition in the .el file.

So now, given that this (humongous) function is the suspect, how do I
proceed with the next steps, which you described as follows:

  When the function is identified I typically construct a single function
  reproducer, for this I typically need the input parameters and I try to
  substitute all other values coming from the environment with something I
  can control.  This step involves understanding which part of the
  environment are captured by the function (say: point, current buffer
  content etc etc...).

  At that point I reduce the function searching for the minimal piece of
  code that behaves differently when native compiled.

  At this point will typically start the "smart" part of the
  investigation.

> >> To force the .elc to be loaded one has to bind `load-no-native' to
> >> non-nil.
> >
> > I think if load-file is invoked interactively, and the user actually
> > types "foo.elc", we need to bind load-no-native non-nil
> > automatically.  Otherwise users would be surprised, as it goes against
> > the logic of what we do when the user types "foo.el".
> 
> We certanly can do this if this is what we want.  This breaks a little
> the idea to have the system as much transparent as possible, I went this
> way cause this was my understanding of what we wanted but I've no strong
> feeling with that.

I don't think this will break the transparent operation, because
loading a package non-interactively (as in when the corresponding
feature is 'require'd by some code) will still load the .eln file.
Only the following 2 use cases will be affected:

  M-x load-file RET /path/to/FOO.elc RET
  M-x load-library RET FOO.elc RET

IOW, when the user loads the file/library interactively, and
explicitly uses the .elc extension, we load the file the user
specified, not the corresponding .eln file.

Previous Next

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