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

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47067@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