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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> I was hit by a segfault while scrolling through a C source file, in
> this case dispnew.c.  The sequence of commands was this:
>
>  emacs -Q
>  C-h sit-for RET
>  Click on the link to subr.el
>  In subr.el go to where sit-for calls sleep-for and type C-h f RET
>  Click on "C source code" to display dispnew.c
>  Scroll down with C-n or C-v

I can't reproduce here :/

> The backtrace appears below, with some data I collected.  The argument
> 'args' to Flss is obviously bogus, but I don't understand how it came
> into existence.  Maybe related to 0x30, which stands for the symbol t?
> The first call-stack frame above that I can examine, frame #4, calls
> c-beginning-of-statement-1 with 4 nil args and the last argument of t.
> The levels below that are impenetrable for me: is there a way of
> digging into this
> F632d626567696e6e696e672d6f662d73746174656d656e742d31_c_beginning_of_statement_1_0
> thing?
>
> Any suggestions for how to debug this further or what data to collect
> that will give you an idea for the root cause(s)?

Assuming is a miscompilation it's gonna be tricky to reduce it without a
reproducible testcase.

But if is a miscompilation is should be reproducible so either is not a
miscompilation or either the initial conditions are different.

> P.S. Note the stopped backtrace: this is something I see for the last
> couple of days on the native-comp branch, not sure if it's related.  I
> will report that separately.
>
> P.P.S. I tried to start another instance of Emacs from the branch, and
> it immediately displayed this:
>
>   Re-entering top level after C stack overflow
>
> Which probably means something unhealthy happens when you start Emacs
> while another instance is under a debugger with the same *.eln files
> loaded.

I often used more than one Emacs session from the same binary so at
least on GNU/Linux this does not appear to be a problem.

Thanks

  Andrea