From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Chang Xiaoduan Newsgroups: gmane.emacs.bugs Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer' Date: Fri, 22 Dec 2023 11:44:57 +0800 Message-ID: References: <838r5qib7l.fsf@gnu.org> <83plz1ggua.fsf@gnu.org> <8334vwgezh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6707"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67900@debbugs.gnu.org, Eli Zaretskii To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 22 04:46:23 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rGWUR-0001Ro-8W for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Dec 2023 04:46:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rGWU6-0004Gm-C9; Thu, 21 Dec 2023 22:46:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rGWU2-0004GU-GM for bug-gnu-emacs@gnu.org; Thu, 21 Dec 2023 22:45:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rGWU2-0000Kb-3l for bug-gnu-emacs@gnu.org; Thu, 21 Dec 2023 22:45:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rGWU6-0005O1-3K for bug-gnu-emacs@gnu.org; Thu, 21 Dec 2023 22:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Chang Xiaoduan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Dec 2023 03:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67900 X-GNU-PR-Package: emacs Original-Received: via spool by 67900-submit@debbugs.gnu.org id=B67900.170321672015650 (code B ref 67900); Fri, 22 Dec 2023 03:46:02 +0000 Original-Received: (at 67900) by debbugs.gnu.org; 22 Dec 2023 03:45:20 +0000 Original-Received: from localhost ([127.0.0.1]:45771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGWTQ-00042B-3U for submit@debbugs.gnu.org; Thu, 21 Dec 2023 22:45:20 -0500 Original-Received: from mail115-171.sinamail.sina.com.cn ([218.30.115.171]:32844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGWTM-0003di-Ok for 67900@debbugs.gnu.org; Thu, 21 Dec 2023 22:45:18 -0500 X-SMAIL-HELO: PWRD-20210716KV Original-Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84]) by sina.com (172.16.235.25) with ESMTP id 6585063900003851; Fri, 22 Dec 2023 11:45:04 +0800 (CST) X-Sender: drcxd@sina.com X-Auth-ID: drcxd@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=drcxd@sina.com X-SMAIL-MID: 70756834209886 X-SMAIL-UIID: 6A7C0E26362442E7AA53687CEF490FF4-20231222-114504-1 In-Reply-To: (Andrea Corallo's message of "Thu, 21 Dec 2023 07:40:16 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276648 Archived-At: Andrea Corallo writes: > Eli Zaretskii writes: > >>> From: Chang Xiaoduan >>> Cc: Andrea Corallo , 67900@debbugs.gnu.org >>> Date: Thu, 21 Dec 2023 11:26:05 +0800 >>> >>> Eli Zaretskii 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