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

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Thu, 11 Mar 2021 11:28:02 UTC

Severity: normal

Found in version 28.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47067 <at> debbugs.gnu.org
Subject: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c
Date: Fri, 12 Mar 2021 19:04:07 +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 16:08:33 +0000
>> 
>> > And the corresponding Lisp backtrace:
>> >
>> >   "c-beginning-of-statement-1" (0x826a08)
>> >   "c-just-after-func-arglist-p" (0x826be0)
>> >   "c-back-over-member-initializers" (0x826db8)
>> >   "c-font-lock-cut-off-declarators" (0x827050)
>> >   "font-lock-fontify-keywords-region" (0x8273a8)
>> >   "font-lock-default-fontify-region" (0x8276b8)
>> >
>> > (Don't ask me why "<", i.e. Flss, doesn't appear in the Lisp
>> > backtrace: something strange happens with backtraces here, as I will
>> > describe in another message.  I think the "??" things in the backtrace
>> > are related.)
>> >
>> > How do I go about finding the function that's responsible for the
>> > problem given the above?  The problem is 100% reproducible for me.
>> 
>> One easy option is to evaluate say `c-beginning-of-statement-1' (as
>> first defendant) and see if afterwards it still crashes.  Same one can
>> load entire files to exclude entirely their content from the equation.
>
> 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.

> (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.

  Andrea




This bug report was last modified 4 years and 44 days ago.

Previous Next


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