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

Previous Next

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 06:46:50 +0000

Eli Zaretskii <eliz <at> 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

Previous Next

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