GNU bug report logs - #67900
30.0.50; Emacs Crahes When Executing Command `consult-buffer'

Previous Next

Full log

Message #23 received at 67900 <at> debbugs.gnu.org (full text, mbox):

From: Chang Xiaoduan <drcxd <at> sina.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#67900: 30.0.50; Emacs Crahes When Executing Command
 `consult-buffer'
Date: Fri, 22 Dec 2023 11:44:57 +0800

Andrea Corallo <acorallo <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Chang Xiaoduan <drcxd <at> sina.com>
>>> Cc: Andrea Corallo <acorallo <at> gnu.org>,  67900 <at> debbugs.gnu.org
>>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>>> 
>>> Eli Zaretskii <eliz <at> 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

I also use Emacs with the same configuration on a Linux system and it
has never crashed while I have been experiencing frequent crashes on
Windows. I think it is not reproducible on Linux.

I have tried to build Emacs with native-compilation on and added a
file-local prop-line in consult.el setting `native-comp-speed` to 1. The
eln cache produced does not trigger the crash. After setting the
file-local property `native-comp-spped` back to 2, I easily reproduced
the crash. Does this indicate that the miscompiled code is inside
consult.el?

I try to find out the minimal code that can reproduce the issue by
starting an Emacs instance with the -Q option. Then I copy the
definition of `consult-buffer` into this instance and evaluate it. If
there is an error, such as missing definition, I try to fix the error by
copying more code and evaluating them. Finally I reached a point that
`consult-buffer` can be executed with no error reported. However, when I
save all copied code to an el file and load it with a clean Emacs (with
-Q option) then I evaluate the buffer and execute `consult-buffer` there
is an error! I have tried this process twice: copying any required code
and execute them piece by piece until `consult-buffer` can be executed
correctly, saving the whole code as an el file then trying to evaluate
it with another clean Emacs instance, it always fails to execute
`consult-buffer` after I evaluate the whole buffer all at once. I have
no idead why this happens since I know not much about emacs lisp.  If
you want I can send you the file. Do you post the content of the file in
E-mail directly or send it as an attachment? Also, when the history of
this communication becomes longer, do I have to keep the content of the
original mails when I reply?

Let me know if there is anything else I can do to help.

Thank you

Previous Next

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