From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer' Date: Fri, 22 Dec 2023 09:41:27 +0200 Message-ID: <83msu2fzvc.fsf@gnu.org> References: <838r5qib7l.fsf@gnu.org> <83plz1ggua.fsf@gnu.org> <8334vwgezh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6085"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67900@debbugs.gnu.org, acorallo@gnu.org To: Chang Xiaoduan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 22 08:42:27 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 1rGaAt-0001Kq-06 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Dec 2023 08:42:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rGaAY-0008ED-Mp; Fri, 22 Dec 2023 02:42:07 -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 1rGaAR-0008Dm-8U for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 02:42:00 -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 1rGaAP-0004bt-T5 for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 02:41:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rGaAU-0000q6-0E for bug-gnu-emacs@gnu.org; Fri, 22 Dec 2023 02:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Dec 2023 07:42:01 +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.17032309143212 (code B ref 67900); Fri, 22 Dec 2023 07:42:01 +0000 Original-Received: (at 67900) by debbugs.gnu.org; 22 Dec 2023 07:41:54 +0000 Original-Received: from localhost ([127.0.0.1]:46004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGaAL-0000pk-Ei for submit@debbugs.gnu.org; Fri, 22 Dec 2023 02:41:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rGaAJ-0000pW-66 for 67900@debbugs.gnu.org; Fri, 22 Dec 2023 02:41:51 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rGaA7-0004Z4-CN; Fri, 22 Dec 2023 02:41:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gq/sHw7xR71dP/dv+HUDrKJCFeQ3flKj/c+jU1gDOPg=; b=hKITBnqp50g1 dNDoh8pdUrD51tkPzbaZ79CnMLZtKTJDNVpE2vF5TozDXFIvtafX0iox3Ph48spSbezppRkHBp0M3 LwEdIcUpEh8NJ+srsriE8SlEdUyz001Zt1S3AGCP1RaqWgcx14pIus7/py47Ta1YQDVaIWM4lcZU6 HaMSgTTvFejinrlXiYfwZlhz3eStTto9J8ONshgIPCm/0GrmFUGF+YWV0cXJsdzXJG5lhVm7o2RYe 74g1HSctigd6H7g+7/F6v7JqNhWDLmMnBnGzWypMLFg7idCQqvtRzwN5gOEqU9e/HE84KZasXl0K9 75v8w0U7BNnvhlsvUqhP/g==; In-Reply-To: (message from Chang Xiaoduan on Fri, 22 Dec 2023 11:44:57 +0800) 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:276649 Archived-At: > From: Chang Xiaoduan > Cc: Eli Zaretskii , 67900@debbugs.gnu.org > Date: Fri, 22 Dec 2023 11:44:57 +0800 > > Andrea Corallo writes: > > > 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). > > 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? It could, but see what Andrea wrote above: it could also be the fault of a few other packages involved in this. So please build Emacs with those 3 packages (bytecomp.el, mule.el, startup.el) natively-compiled with native-comp-speed = 1, then native-compile consult.el with native-comp-speed = 2, and see if you still see the crashes. If yes, then consult.el is probably the one that triggers the bug. If compiling those 3 other packages with native-comp-speed = 1 eliminates the crashes, then we need to look for the one of those 3 which triggers the crash, and continue narrowing this down from there. > 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. What is the error you see after you evaluate the whole code? It might be that the order of the code in the el file matters, and you need to reorder the functions and variables there. But I think finding the minimal Lisp code which, when native-compiled with native-comp-speed = 2, triggers the crashes is more important. Thanks.