bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chang Xiaoduan <drcxd@sina.com>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  67900@debbugs.gnu.org
>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>> >
>> 
>> This is the first time I report an Emacs bug using E-mails and I am not
>> familiar with this kind of workflow for reporting a bug and
>> communication. I have raised some issues on GitHub but that is totally
>> different and more intuitive. Would you mind introducing me how such a
>> workflow came into being and why you stick with it? Any links to wiki or
>> articles are welcomed.
>
> It's a long story.  In a nutshell, we use email because doing that,
> together with some features of the debbugs issue tracker, makes it
> very easy to do everything from Emacs: review patches and send
> feedback for patches, apply patches that are approved, manage issues
> (open, close, and reopen them, add and remove tags to issues, etc.),
> and do other jobs.
>
> We are looking into switching to a different issue tracker, which
> would allow also PR-based workflows and a browser UI to do some of
> these jobs, but so far every tracker we've examined needed additions
> and improvements to satisfy our needs, and so we haven't switched yet.
>
>> > The above seems to indicate the problems are somehow related to native
>> > compilation.  Can you build Emacs without native-compilation, and try
>> > reproducing this in such an Emacs?  If the problem doesn't happen in
>> > Emacs without native-compilation, I suspect this is a MinGW GCC bug,
>> > not an Emacs bug: the native code in *.eln files is somehow invalid.
>> 
>> I can not reproduce the crash using Emacs without native-compilation.
>> 
>> >
>> > Which version of GCC do you have installed, and is libgccjit you have
>> > is from the same GCC version?
>> 
>> I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.
>> 
>> >
>> > Or maybe we have a bug in native compilation.  Andrea, can you try
>> > reproducing this on GNU/Linux?
>> >
>> > Another idea is to modify comp.el to have native-comp-speed default to
>> > 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
>> > and see if the problem goes away.  If it does, that again points
>> > toward GCC/libgccjit and the compiler optimizations.
>> 
>> I have modified the `native-comp-speed` to 1, but not specified
>> `CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
>> the same crash.
>> 
>> After all, it looks like Eli's assumption is likely to be true. If you
>> are familiar with reporting a compiler bug, could you tell me how could
>> I verify it is indeed a MinGW GCC bug and report this to MinGW?
>
> Andrea, can you please help Chang Xiaoduan to create a reproducer in
> this case, and examine it by comparing with what you see when you
> native-compile consult-buffer on your system?  Maybe we could somehow
> work around this in Emacs, since IME the libgccjit folks are not very
> responsive to MinGW-specific bugs.

I tried to reproduce on my system (GNU Emacs 30.0.50 (build 1,
x86_64-pc-linux-gnu) of 2023-12-21) with no success.

I think a starting point would be to identify which one is the
compilation unit that gets misscompiled, the second will be to indentify
the function.

I'd proceed bisecting the compilations unit in Emacs core and in the
packages involved adding the "no-native-compile: t" cookie to the file.

But before starting with a blind bisect I think we should try if any of
the .eln present in the back trace is the responsible, AFAICS those are:
bytecomp.el, mule.el, startup.el (with the first being the suspect nr1).

Thanks

  Andrea