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

Previous Next

Full log

Message #59 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: 47067 <at> debbugs.gnu.org
Subject: Re: 28.0.50; [feature/native-comp] Crash while scrolling through
 dispnew.c
Date: Fri, 12 Mar 2021 20:10:27 +0000

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

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 47067 <at> debbugs.gnu.org
>> Date: Fri, 12 Mar 2021 19:04:07 +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...

>
>> > (Btw, if I load cc-engine.elc, it says it loads the .eln file
>> > instead?  is that intentional?)
>> 
>> Yes, .eln load is "transparent" and triggered automatically while
>> loading a .elc file when the corresponding .eln is found in the
>> `comp-eln-load-path'.
>> 
>> 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.

Thanks

  Andrea

Previous Next

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