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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

Another idea would be to build Emacs with native-compilation as usual,
with native-comp-speed set to 2, but then compile only consult.el with
native-comp-speed set to 1.  If that also solves the problem, we will
know that something in consult.el triggers the problem, and could
perhaps try narrowing down the problem to some very specific code in
consult.el.

Thanks.