all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chang Xiaoduan <drcxd@sina.com>
To: Andrea Corallo <acorallo@gnu.org>
Cc: 67900@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Date: Fri, 22 Dec 2023 11:44:57 +0800	[thread overview]
Message-ID: <m3ttoaaojq.fsf@sina.com> (raw)
In-Reply-To: <yp1msu3zq33.fsf@fencepost.gnu.org> (Andrea Corallo's message of "Thu, 21 Dec 2023 07:40:16 -0500")

Andrea Corallo <acorallo@gnu.org> writes:

> 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

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





  reply	other threads:[~2023-12-22  3:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19  7:48 bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer' Chang Xiaoduan
2023-12-19 13:16 ` Eli Zaretskii
     [not found]   ` <m3msu5751x.fsf@sina.com>
2023-12-20 13:10     ` Eli Zaretskii
2023-12-21  3:26       ` Chang Xiaoduan
2023-12-21  8:02         ` Eli Zaretskii
2023-12-21 12:40           ` Andrea Corallo
2023-12-22  3:44             ` Chang Xiaoduan [this message]
2023-12-22  7:41               ` Eli Zaretskii
2023-12-22  9:38                 ` Andrea Corallo
2023-12-23  2:30                 ` Chang Xiaoduan
2023-12-23  7:35                   ` Eli Zaretskii
2023-12-26  8:32                     ` Andrea Corallo
2023-12-28 11:44                       ` Chang Xiaoduan
2023-12-29 18:37                         ` Andrea Corallo
2024-01-02  7:24                           ` Chang Xiaoduan
2024-01-04  9:51                             ` Andrea Corallo
2024-01-05  7:04                               ` Chang Xiaoduan
2024-01-05 21:46                                 ` Andrea Corallo
2024-01-08  3:28                                   ` Chang Xiaoduan
2024-01-08 10:35                                     ` Andrea Corallo
2024-01-08 11:40                                       ` Chang Xiaoduan
2024-01-09  9:58                                         ` Andrea Corallo
2024-01-02  8:20                           ` Chang Xiaoduan
2024-01-04  9:58                             ` Andrea Corallo
2024-01-05  4:22                             ` Richard Stallman
2024-01-05  7:09                               ` Chang Xiaoduan
2024-01-07  4:29                                 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3ttoaaojq.fsf@sina.com \
    --to=drcxd@sina.com \
    --cc=67900@debbugs.gnu.org \
    --cc=acorallo@gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.