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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47067@debbugs.gnu.org
>> Date: Fri, 12 Mar 2021 12:04:34 +0000
>> 
>> >> >  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 :/
>> >
>> > Did you try the 32-bit build --with-wide-int?  It could be specific to
>> > that configuration.
>> 
>> Good point, it tried on 32-bit before and now 32-bit --with-wide-int but
>> still could not reproduce.
>
> Is there any data I can collect to help diagnose the issue?  Anything
> at all?  Like maybe disassembly of this 
> F632d626567696e6e696e672d6f662d73746174656d656e742d31_c_beginning_of_statement_1_0()
> function or some part of it?
>
> IOW, if the problem is miscompilation to native code, what facilities
> do we have to report the details if the simple recipe doesn't
> reproduce the problem?  We will have this kind of problems in the near
> future, so having a good way of reporting the details might help
> eliminate bugs faster.

Generally speaking the first step is to identify the function that is
responsible for the bug, this is often on the top of the back-trace but
not necessarily.  In the unfortunate case I typically proceed by
bisection.

When the function is identified I typically construct a single function
reproducer, for this I typically need the input parameters and I try to
substitute all other values coming from the environment with something I
can control.  This step involve understanding which part of the
environment are captured by the function (say: point, current buffer
content etc etc...).

At that point I reduce the function searching for the minimal piece of
code that behaves differently when native compiled.

At this point will typically start the "smart" part of the
investigation.

Here the problem is that being not reproducible we are stuck in the
first steps, reproducibility is tipically a pre for this kind of
analysis.  But again if it's a miscompilation it *must* be reproducible
because code is not morphing so probably we are not reproducing it
precisely?

BTW cc-engine.el is dynamic scope, this means we do not perform any
optimization in comp.el and we perform a bare 1:1 translation, so at
this stage I'd be rather skeptical this is miscompiled.

Thanks

  Andrea