From unknown Sat Aug 09 04:52:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#68690 <68690@debbugs.gnu.org> To: bug#68690 <68690@debbugs.gnu.org> Subject: Status: Segmentation fault building with native-comp Reply-To: bug#68690 <68690@debbugs.gnu.org> Date: Sat, 09 Aug 2025 11:52:43 +0000 retitle 68690 Segmentation fault building with native-comp reassign 68690 emacs submitter 68690 john muhl severity 68690 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 11:43:47 2024 Received: (at submit) by debbugs.gnu.org; 24 Jan 2024 16:43:47 +0000 Received: from localhost ([127.0.0.1]:46420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSgLr-00028G-8H for submit@debbugs.gnu.org; Wed, 24 Jan 2024 11:43:47 -0500 Received: from lists.gnu.org ([2001:470:142::17]:51830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSgLp-000283-68 for submit@debbugs.gnu.org; Wed, 24 Jan 2024 11:43:46 -0500 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 1rSgLe-0003Zi-HN for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 11:43:34 -0500 Received: from out-182.mta0.migadu.com ([91.218.175.182]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rSgLc-0004f2-GM for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 11:43:34 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pub.pink; s=key1; t=1706114608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nT3g5t44UIai9TpKJtvzmuQqpn0m5CRTa83ace3fgfQ=; b=ZiSzFZtU07AKrOwTHwzCfZ2srxbssOTwPgkD/nZrh+/YEYb+TqEbYKi7ASS9JlrjRJ6eKq iozZSCatKEPTJRTiFH7y3p/EMnWh2v8jH7jvT/HQRVXCTgSXPZtbZqJroLKfwvzdVccsRB in/dNzkjUh7mibYzyQh+9CVGxzLD4dQ= From: john muhl To: bug-gnu-emacs@gnu.org Subject: Segmentation fault building with native-comp Date: Wed, 24 Jan 2024 08:36:15 -0600 Message-ID: <87wmryel78.fsf@pub.pink> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=91.218.175.182; envelope-from=jm@pub.pink; helo=out-182.mta0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Bisect says 3018c6e7ba5 is the first bad commit. A build using =E2=80=98--without-native-compilation=E2=80=99 works fine. The segfault can= be reproduced on Fedora 39 and Debian testing. make bootstrap =E2=80=A6 make -C ../lisp compile-first EMACS=3D"../src/bootstrap-emacs" make[3]: Entering directory '/home/jm/src/emacs-0/lisp' ELC+ELN emacs-lisp/macroexp.elc ELC+ELN emacs-lisp/cconv.elc ELC+ELN emacs-lisp/byte-opt.elc ELC+ELN emacs-lisp/bytecomp.elc ELC+ELN emacs-lisp/comp.elc ELC+ELN emacs-lisp/comp-cstr.elc ELC+ELN emacs-lisp/comp-common.elc ELC+ELN emacs-lisp/comp-run.elc ELC+ELN emacs-lisp/loaddefs-gen.elc ELC+ELN emacs-lisp/radix-tree.elc Backtrace: ../src/bootstrap-emacs[0x57863b] ../src/bootstrap-emacs[0x42651e] ../src/bootstrap-emacs[0x426a10] ../src/bootstrap-emacs[0x576cf8] ../src/bootstrap-emacs[0x576d69] /lib64/libc.so.6(+0x3e9a0)[0x7fce2b5089a0] ../src/bootstrap-emacs[0x60bb50] ../src/bootstrap-emacs[0x60df74] ../src/bootstrap-emacs[0x5e8910] ../src/bootstrap-emacs[0x5e9891] ../src/bootstrap-emacs[0x5e9d8c] ../src/bootstrap-emacs[0x5e8111] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e9891] ../src/bootstrap-emacs[0x5e4fe6] ../src/bootstrap-emacs[0x5e5d3a] ../src/bootstrap-emacs[0x428f09] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0+0xaeb)[0= x7fce281a030b] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F62617463682d6e61746976652d636f6d70696c65_batch_native_compile_0+0x186)[0= x7fce281a0c26] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F62617463682d627974652b6e61746976652d636f6d70696c65_batch_bytenative_comp= ile_0+0x144)[0x7fce281a0f84] ../src/bootstrap-emacs[0x5e4fe6] ../src/bootstrap-emacs[0x5e860d] ../src/bootstrap-emacs[0x5e9251] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e92d9] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea5d1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e9101] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea5d1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e8ab1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea1b9] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea1b9] ... make[3]: *** [Makefile:330: emacs-lisp/byte-opt.elc] Segmentation fault (co= re dumped) make[3]: *** Waiting for unfinished jobs.... Backtrace: ../src/bootstrap-emacs[0x57863b] ../src/bootstrap-emacs[0x42651e] ../src/bootstrap-emacs[0x426a10] ../src/bootstrap-emacs[0x576cf8] ../src/bootstrap-emacs[0x576d69] /lib64/libc.so.6(+0x3e9a0)[0x7f8c2be5c9a0] ../src/bootstrap-emacs[0x60b9e0] ../src/bootstrap-emacs[0x60df74] ../src/bootstrap-emacs[0x5e8910] ../src/bootstrap-emacs[0x5e9891] ../src/bootstrap-emacs[0x5e9d8c] ../src/bootstrap-emacs[0x5e8111] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e9891] ../src/bootstrap-emacs[0x5e4fe6] ../src/bootstrap-emacs[0x5e5d3a] ../src/bootstrap-emacs[0x428f09] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0+0xaeb)[0= x7f8c28abf30b] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F62617463682d6e61746976652d636f6d70696c65_batch_native_compile_0+0x186)[0= x7f8c28abfc26] ../src/bootstrap-emacs[0x5e4fe6] /home/jm/src/emacs-0/native-lisp/30.0.50-ed70e66e/comp-7672a6ed-93f96353.el= n(F62617463682d627974652b6e61746976652d636f6d70696c65_batch_bytenative_comp= ile_0+0x144)[0x7f8c28abff84] ../src/bootstrap-emacs[0x5e4fe6] ../src/bootstrap-emacs[0x5e860d] ../src/bootstrap-emacs[0x5e9251] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e92d9] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea5d1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e9101] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea5d1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e8ab1] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea1b9] ../src/bootstrap-emacs[0x5e87f7] ../src/bootstrap-emacs[0x5ea1b9] ... make[3]: *** [Makefile:330: emacs-lisp/bytecomp.elc] Segmentation fault (co= re dumped) make[3]: Leaving directory '/home/jm/src/emacs-0/lisp' make[2]: *** [Makefile:1019: bootstrap-emacs.pdmp] Error 2 make[2]: Leaving directory '/home/jm/src/emacs-0/src' make[1]: *** [Makefile:554: src] Error 2 make[1]: Leaving directory '/home/jm/src/emacs-0' make[1]: Entering directory '/home/jm/src/emacs-0' *** *** "make all" failed with exit status 2. *** *** You could try to: *** - run "make bootstrap", which might fix the problem *** - run "make V=3D1", which displays the full commands invoked by make, *** to further investigate the problem *** make[1]: *** [Makefile:418: advice-on-failure] Error 2 make[1]: Leaving directory '/home/jm/src/emacs-0' make: *** [Makefile:374: all] Error 2 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 12:11:14 2024 Received: (at 68690) by debbugs.gnu.org; 24 Jan 2024 17:11:14 +0000 Received: from localhost ([127.0.0.1]:46488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSgmQ-00031N-5G for submit@debbugs.gnu.org; Wed, 24 Jan 2024 12:11:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSgmO-000315-8T for 68690@debbugs.gnu.org; Wed, 24 Jan 2024 12:11:12 -0500 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 1rSgmC-0003IF-P8; Wed, 24 Jan 2024 12:11:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=diGrCKq1fxX4mIL3ozBXWzdXILVVpgMLoc56EKdNwNg=; b=V1bVcuSej6U6gHgdyy02 H8Ae+EqYImXxOeQnd1abGssnAAtFa8tft7Sy4mbQs4Tmh1wwgXaNFc1+ADSYJYPDAmRYQtaHmwKo0 kqB/FbhdMGRzFnxaRp77QQcfqhWubMbvbTYdSPezO4xiuPCv1CiF5JRpOLiDbXaCeAV5Uw4UvbsOH Rvusc3ne1b9mrkbDrDU1rpWPt7dSUOmNnSCE8W/87fphZ2RrXiuMQYwph1FNVQmhMnAf76rrXJJe4 PdwuuQuYn3NKQTufB43zqpzj4E/dPKrKmhmvioD3UBmFE4+Bsw5OSBOzsDBjp651baCfpG8llsUPW tEZh+1OEIkc8NQ==; Date: Wed, 24 Jan 2024 19:10:56 +0200 Message-Id: <86zfwud5cv.fsf@gnu.org> From: Eli Zaretskii To: john muhl , Stefan Monnier In-Reply-To: <87wmryel78.fsf@pub.pink> (bug-gnu-emacs@gnu.org) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 24 Jan 2024 08:36:15 -0600 > From: john muhl via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Bisect says 3018c6e7ba5 is the first bad commit. A build using > ‘--without-native-compilation’ works fine. The segfault can be > reproduced on Fedora 39 and Debian testing. > > make bootstrap > … > make -C ../lisp compile-first EMACS="../src/bootstrap-emacs" > make[3]: Entering directory '/home/jm/src/emacs-0/lisp' > ELC+ELN emacs-lisp/macroexp.elc > ELC+ELN emacs-lisp/cconv.elc > ELC+ELN emacs-lisp/byte-opt.elc > ELC+ELN emacs-lisp/bytecomp.elc > ELC+ELN emacs-lisp/comp.elc > ELC+ELN emacs-lisp/comp-cstr.elc > ELC+ELN emacs-lisp/comp-common.elc > ELC+ELN emacs-lisp/comp-run.elc > ELC+ELN emacs-lisp/loaddefs-gen.elc > ELC+ELN emacs-lisp/radix-tree.elc > > Backtrace: > ../src/bootstrap-emacs[0x57863b] > ../src/bootstrap-emacs[0x42651e] Adding Stefan, who installed that commit. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 14:53:06 2024 Received: (at 68690) by debbugs.gnu.org; 24 Jan 2024 19:53:06 +0000 Received: from localhost ([127.0.0.1]:46657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjJ3-0001zu-G2 for submit@debbugs.gnu.org; Wed, 24 Jan 2024 14:53:06 -0500 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:42109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjJ0-0001zO-RD for 68690@debbugs.gnu.org; Wed, 24 Jan 2024 14:53:03 -0500 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a313b51cf1fso5409266b.0 for <68690@debbugs.gnu.org>; Wed, 24 Jan 2024 11:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706125971; x=1706730771; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mc1FiomrlGyHs/6cpyuxQEgoj+wY9woMRAixCXteDkI=; b=OPWUXkyHIQWLRYfWFB5/mqZeyGG3k46sPd/RJsm/fa8/OlaD8tFB2/WtPzg5862JBA 5GuYUomxvGaQ1WdUVlrwtYsGPYYxPFeTFo/huCxd/Wct+btvt+QzkAZlE0uNR46ZNLNI ODER0cl3ybcIZirp02BX9b+4NDgztj7bOSFV9FgTiYoKbFkEFyW9VQN6UfnAD7AokcLP D6fmJDYkXLfVTfGEECn9ddI2S2vrmV1vLWPqW8siSLZhwVS07Io7w1hFYsxBQ3gkDWIw CPfvcnOMS9qqJ0CS4rsNuWsJxBOtPLOiZKMlD1jNAQ0DIREwnh11h+8M4ahV/FKhgV3Q +nUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706125971; x=1706730771; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mc1FiomrlGyHs/6cpyuxQEgoj+wY9woMRAixCXteDkI=; b=xPRl9+o/bxSM9/nC200Ww/9/nYRJ9AQj80hmZ4ShdmUm7g1oon/XXMNYGRHJ9v1xAL u/lSvVqhlSX+zEtorHaXmVPG4ASs9cWxeqr1BX0TPFgzdU2qvEkb6hNk635xuRHf4UTZ GjQn/xTqL//Kt6hAWZfCtHJiLbp0PcQB1E92yrqaBYIb4EobFoo60XNWZs/agjQYq0n1 nDN45w51wZUGZuqQ6knzssqkuEGz4/Pk6Ux5kbk3X2r8Dteg48LvSouyB8rrXAeNNHM4 cNxAzfb3m2GA8Xdconvp15r+5vSZ0PUvczpJs/546Qi8tASkP8KbfhTegkaiS8CVpa7/ fipA== X-Gm-Message-State: AOJu0YxMHFrsnhrqPtcA6PnL/Ei2cO4p3ZbKH/T3wf/kdpW2Wq/ZYuKA tk8ZnlENN6+cB5cyTZ5jXMC0zI7X/J6WHA4rnJv3FFT0WZNg6XqQeck8j/tR X-Google-Smtp-Source: AGHT+IG0PT++ICyHi3itcqpJs4JKWJN0Q1B8XzuX/idGqoxA1dKkAX8aieRxPk7iQohuWPZcE4sPww== X-Received: by 2002:a17:906:ba87:b0:a31:61ad:c94f with SMTP id cu7-20020a170906ba8700b00a3161adc94fmr149056ejd.12.1706125970944; Wed, 24 Jan 2024 11:52:50 -0800 (PST) Received: from Pro.fritz.box (p4fe3acfb.dip0.t-ipconnect.de. [79.227.172.251]) by smtp.gmail.com with ESMTPSA id nc18-20020a1709071c1200b00a2ca97242d5sm200853ejc.120.2024.01.24.11.52.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 11:52:50 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86zfwud5cv.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Jan 2024 19:10:56 +0200") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> Date: Wed, 24 Jan 2024 20:52:49 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68690 Cc: john muhl , 68690@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Wed, 24 Jan 2024 08:36:15 -0600 >> From: john muhl via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >>=20 >> Bisect says 3018c6e7ba5 is the first bad commit. A build using >> =E2=80=98--without-native-compilation=E2=80=99 works fine. The segfault = can be >> reproduced on Fedora 39 and Debian testing. >>=20 >> make bootstrap >> =E2=80=A6 >> make -C ../lisp compile-first EMACS=3D"../src/bootstrap-emacs" >> make[3]: Entering directory '/home/jm/src/emacs-0/lisp' >> ELC+ELN emacs-lisp/macroexp.elc >> ELC+ELN emacs-lisp/cconv.elc >> ELC+ELN emacs-lisp/byte-opt.elc >> ELC+ELN emacs-lisp/bytecomp.elc >> ELC+ELN emacs-lisp/comp.elc >> ELC+ELN emacs-lisp/comp-cstr.elc >> ELC+ELN emacs-lisp/comp-common.elc >> ELC+ELN emacs-lisp/comp-run.elc >> ELC+ELN emacs-lisp/loaddefs-gen.elc >> ELC+ELN emacs-lisp/radix-tree.elc >>=20 >> Backtrace: >> ../src/bootstrap-emacs[0x57863b] >> ../src/bootstrap-emacs[0x42651e] > > Adding Stefan, who installed that commit. FWIW, in an ASAN build, I see an abort. This is with 1f3371b46e8a6a51f88c56785175b48af2a0bed7, on macOS. ELC+ELN emacs-lisp/macroexp.elc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D32930=3D=3DERROR: AddressSanitizer: heap-use-after-free on address 0x= 60c0000353e0 at pc 0x000102b3fc97 bp 0x7ff7bdaf7250 sp 0x7ff7bdaf7248 READ of size 8 at 0x60c0000353e0 thread T0 #0 0x102b3fc96 in Fmaphash fns.c:5665 #1 0x102b062c8 in funcall_subr eval.c:3092 #2 0x102bf85af in exec_byte_code bytecode.c:815 #3 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #4 0x102b0766b in funcall_lambda eval.c:3207 #5 0x102b05b80 in funcall_general eval.c:2972 #6 0x102af5c86 in Ffuncall eval.c:3022 #7 0x102b3fdee in Fmaphash fns.c:5666 #8 0x102b062c8 in funcall_subr eval.c:3092 #9 0x102bf85af in exec_byte_code bytecode.c:815 #10 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #11 0x102b0766b in funcall_lambda eval.c:3207 #12 0x102b05b80 in funcall_general eval.c:2972 #13 0x102af5c86 in Ffuncall eval.c:3022 #14 0x102af238f in eval_sub eval.c:2497 #15 0x102af4477 in Fprogn eval.c:432 #16 0x102af429d in Fif eval.c:388 #17 0x102af1ecc in eval_sub eval.c:2476 #18 0x102af4477 in Fprogn eval.c:432 #19 0x102af46ae in Fcond eval.c:412 #20 0x102af1ecc in eval_sub eval.c:2476 #21 0x102af4477 in Fprogn eval.c:432 #22 0x102af908b in FletX eval.c:972 #23 0x102af1ecc in eval_sub eval.c:2476 #24 0x102af4477 in Fprogn eval.c:432 #25 0x102af4754 in prog_ignore eval.c:443 #26 0x102afa345 in Fwhile eval.c:1061 #27 0x102af1ecc in eval_sub eval.c:2476 #28 0x102af4477 in Fprogn eval.c:432 #29 0x102af908b in FletX eval.c:972 #30 0x102af1ecc in eval_sub eval.c:2476 #31 0x102af4477 in Fprogn eval.c:432 #32 0x102af1ecc in eval_sub eval.c:2476 #33 0x102af4244 in Fif eval.c:387 #34 0x102af1ecc in eval_sub eval.c:2476 #35 0x102af4477 in Fprogn eval.c:432 #36 0x102af9d17 in Flet eval.c:1040 #37 0x102af1ecc in eval_sub eval.c:2476 #38 0x102af4477 in Fprogn eval.c:432 #39 0x102af9d17 in Flet eval.c:1040 #40 0x102af1ecc in eval_sub eval.c:2476 #41 0x102af4477 in Fprogn eval.c:432 #42 0x102b07db5 in funcall_lambda eval.c:3287 #43 0x102b03941 in apply_lambda eval.c:3157 #44 0x102af3d68 in eval_sub eval.c:2615 #45 0x102af4477 in Fprogn eval.c:432 #46 0x102af9d17 in Flet eval.c:1040 #47 0x102af1ecc in eval_sub eval.c:2476 #48 0x102af4477 in Fprogn eval.c:432 #49 0x102b07db5 in funcall_lambda eval.c:3287 #50 0x102b03941 in apply_lambda eval.c:3157 #51 0x102af3d68 in eval_sub eval.c:2615 #52 0x102afb992 in Funwind_protect eval.c:1321 #53 0x102af1ecc in eval_sub eval.c:2476 #54 0x102af4477 in Fprogn eval.c:432 #55 0x102af9d17 in Flet eval.c:1040 #56 0x102af1ecc in eval_sub eval.c:2476 #57 0x102af4477 in Fprogn eval.c:432 #58 0x102af429d in Fif eval.c:388 #59 0x102af1ecc in eval_sub eval.c:2476 #60 0x102af4477 in Fprogn eval.c:432 #61 0x102b07db5 in funcall_lambda eval.c:3287 #62 0x102b03941 in apply_lambda eval.c:3157 #63 0x102af3d68 in eval_sub eval.c:2615 #64 0x102b02223 in Feval eval.c:2389 #65 0x1028d087a in top_level_2 keyboard.c:1173 #66 0x102afd8e8 in internal_condition_case eval.c:1537 #67 0x1028d06e0 in top_level_1 keyboard.c:1185 #68 0x102afb4b5 in internal_catch eval.c:1217 #69 0x10288e149 in command_loop keyboard.c:1134 #70 0x10288db6d in recursive_edit_1 keyboard.c:744 #71 0x10288eb2c in Frecursive_edit keyboard.c:827 #72 0x1028867be in main emacs.c:2624 #73 0x7ff808461385 in start+0x795 (dyld:x86_64+0xfffffffffff5c385) 0x60c0000353e0 is located 96 bytes inside of 128-byte region [0x60c00003538= 0,0x60c000035400) freed by thread T0 here: #0 0x1052b0e16 in free+0xa6 (libclang_rt.asan_osx_dynamic.dylib:x86_64h= +0xe0e16) #1 0x102eca876 in rpl_free free.c:48 #2 0x102a567bf in xfree alloc.c:831 #3 0x102a5eada in hash_table_free_bytes alloc.c:5653 #4 0x102b3b781 in maybe_resize_hash_table fns.c:4723 #5 0x102b3ae12 in hash_put fns.c:4864 #6 0x102b3fa6f in Fputhash fns.c:5639 #7 0x102b06416 in funcall_subr eval.c:3094 #8 0x102bf85af in exec_byte_code bytecode.c:815 #9 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #10 0x102b0766b in funcall_lambda eval.c:3207 #11 0x102b05b80 in funcall_general eval.c:2972 #12 0x102af5c86 in Ffuncall eval.c:3022 #13 0x102b3fdee in Fmaphash fns.c:5666 #14 0x102b062c8 in funcall_subr eval.c:3092 #15 0x102bf85af in exec_byte_code bytecode.c:815 #16 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #17 0x102b0766b in funcall_lambda eval.c:3207 #18 0x102b05b80 in funcall_general eval.c:2972 #19 0x102af5c86 in Ffuncall eval.c:3022 #20 0x102b3fdee in Fmaphash fns.c:5666 #21 0x102b062c8 in funcall_subr eval.c:3092 #22 0x102bf85af in exec_byte_code bytecode.c:815 #23 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #24 0x102b0766b in funcall_lambda eval.c:3207 #25 0x102b05b80 in funcall_general eval.c:2972 #26 0x102af5c86 in Ffuncall eval.c:3022 #27 0x102af238f in eval_sub eval.c:2497 #28 0x102af4477 in Fprogn eval.c:432 #29 0x102af429d in Fif eval.c:388 previously allocated by thread T0 here: #0 0x1052b0ccd in malloc+0x9d (libclang_rt.asan_osx_dynamic.dylib:x86_6= 4h+0xe0ccd) #1 0x102a564bd in lmalloc alloc.c:1402 #2 0x102a563d6 in xmalloc alloc.c:772 #3 0x102a5ea87 in hash_table_alloc_bytes alloc.c:5644 #4 0x102b3b295 in maybe_resize_hash_table fns.c:4700 #5 0x102b3ae12 in hash_put fns.c:4864 #6 0x102b3fa6f in Fputhash fns.c:5639 #7 0x102b06416 in funcall_subr eval.c:3094 #8 0x102bf85af in exec_byte_code bytecode.c:815 #9 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #10 0x102b0766b in funcall_lambda eval.c:3207 #11 0x102b05b80 in funcall_general eval.c:2972 #12 0x102af5c86 in Ffuncall eval.c:3022 #13 0x102b3fdee in Fmaphash fns.c:5666 #14 0x102b062c8 in funcall_subr eval.c:3092 #15 0x102bf85af in exec_byte_code bytecode.c:815 #16 0x102b0fd66 in fetch_and_exec_byte_code eval.c:3135 #17 0x102b0766b in funcall_lambda eval.c:3207 #18 0x102b05b80 in funcall_general eval.c:2972 #19 0x102af5c86 in Ffuncall eval.c:3022 #20 0x102af238f in eval_sub eval.c:2497 #21 0x102af4477 in Fprogn eval.c:432 #22 0x102af429d in Fif eval.c:388 #23 0x102af1ecc in eval_sub eval.c:2476 #24 0x102af4477 in Fprogn eval.c:432 #25 0x102af46ae in Fcond eval.c:412 #26 0x102af1ecc in eval_sub eval.c:2476 #27 0x102af4477 in Fprogn eval.c:432 #28 0x102af908b in FletX eval.c:972 #29 0x102af1ecc in eval_sub eval.c:2476 SUMMARY: AddressSanitizer: heap-use-after-free fns.c:5665 in Fmaphash Shadow bytes around the buggy address: 0x60c000035100: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x60c000035180: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x60c000035200: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x60c000035280: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x60c000035300: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa =3D>0x60c000035380: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd 0x60c000035400: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x60c000035480: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x60c000035500: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x60c000035580: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x60c000035600: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D32930=3D=3DABORTING Fatal error 6: Aborted From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 14:58:13 2024 Received: (at 68690) by debbugs.gnu.org; 24 Jan 2024 19:58:13 +0000 Received: from localhost ([127.0.0.1]:46667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjO0-00027W-Un for submit@debbugs.gnu.org; Wed, 24 Jan 2024 14:58:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjNy-00027I-F8 for 68690@debbugs.gnu.org; Wed, 24 Jan 2024 14:58:11 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 398A010007D; Wed, 24 Jan 2024 14:57:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706126278; bh=lWxq+s5RZvIGrc9Xhm+4OS5y+osBTY7KUS3IUMlSlTo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R/Xr8SDZEXzh+Hhoy4e9ywnMfWZQNQyvcjM8D+eMywziYSF0JOmupLbkISqQ1cVyi SpQp8xCLElTRscREKWCCjNGY0mrXUC6VLOOOhtiv6FcTU7DJzowKH/lBEp7iJDD7KW yoNzqtujrl62A0NtTyRI3Xsud4+XXLcwt8RUKnFEeFnbblI7BcohNqvmTqTicfsm2n 3c9bch6R3/NmqcaqzQ5TwVF5cgjPkY/AQ1ChztEh+tz6YZ86EIOqWfYDOVEQIln08d tek38VAos6WgqFZx8effxjL1YQnxAqNKrDlu5mLKwLQPqZdhv7xph1WZhTmZcdgAEq bcTgFy9ZhB5gQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4F23510001D; Wed, 24 Jan 2024 14:57:58 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 34268120971; Wed, 24 Jan 2024 14:57:58 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86zfwud5cv.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Jan 2024 19:10:56 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> Date: Wed, 24 Jan 2024 14:56:49 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.260 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: john muhl , 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Adding Stefan, who installed that commit. Oops, should be fixed now, Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 15:27:21 2024 Received: (at 68690) by debbugs.gnu.org; 24 Jan 2024 20:27:21 +0000 Received: from localhost ([127.0.0.1]:46688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjqD-0002pf-3e for submit@debbugs.gnu.org; Wed, 24 Jan 2024 15:27:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:32988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSjqA-0002pS-R0 for 68690@debbugs.gnu.org; Wed, 24 Jan 2024 15:27:19 -0500 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 1rSjpy-00056e-Ve; Wed, 24 Jan 2024 15:27:07 -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=pXLAmPrXjgTEQDgYmMJgTrZGOp4X9BBIvZz4fEdwdeQ=; b=mWMpB1aJtF9b Zqr3zLI6gkoVAiclNo1DjTJLfqIxFl5P7FPRcg8CzMHjyivVSsszXPTzMvYB6BXTuTlDaEW0frN2R 6483utlXlUnYZ9uAn1loH8U/yRDjucu+Lw2eTJm2sIOp1kc7yZMRObhRu3ja41SQriaBiBG2vtRtL rAei2F6UBly9xn303Pim+R/Tp19RqRQ3HkCl/szbXnuP/DuJ+pvWATIFnDuVSwdqci+jGkKW4vjr9 oT8xA+JemBW8FCES6QSaFW9AmWazdrfXHhY1FW3ipjnwCfrWFfGw10d08LtxrAyUebI8mqO3nKRsv YY6xBy7vaaohiVJKu3kUug==; Date: Wed, 24 Jan 2024 22:27:01 +0200 Message-Id: <86sf2mcwa2.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 24 Jan 2024 14:56:49 -0500) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: john muhl , 68690@debbugs.gnu.org > Date: Wed, 24 Jan 2024 14:56:49 -0500 > > > Adding Stefan, who installed that commit. > > Oops, should be fixed now, The build now crashes here (this is a 32-bit build with large ints): '../src/bootstrap-emacs.exe' -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--inhibit-version-check t)" \ -l bytecomp -f byte-compile-refresh-preloaded \ -f batch-byte-compile ../lisp/mwheel.el lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) Here's the backtrace from GDB: lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 442 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 #1 0x00772401 in die (msg=0xddc80d "VECTORLIKEP (a)", file=0xddc740 "lisp.h", line=1784) at alloc.c:8062 #2 0x00626a44 in XVECTOR (a=XIL(0x92348b000000000)) at lisp.h:1784 #3 0x00626ace in gc_asize (array=XIL(0x92348b000000000)) at lisp.h:1800 #4 0x00626bba in AREF (array=XIL(0x92348b000000000), idx=1) at lisp.h:1971 #5 0x0063174d in Fcharset_after (pos=make_fixnum(113)) at charset.c:2084 #6 0x007ba520 in funcall_subr (subr=0xdb7a80 , numargs=1, args=0x9d14a08) at eval.c:3090 #7 0x0082d5b7 in exec_byte_code (fun=XIL(0xa0000000091dcec8), args_template=0, nargs=0, args=0x9d14a08) at bytecode.c:815 #8 0x007baafa in fetch_and_exec_byte_code (fun=XIL(0xa000000009136058), args_template=642, nargs=10, args=0x5dce628) at eval.c:3135 #9 0x007bb059 in funcall_lambda (fun=XIL(0xa000000009136058), nargs=10, arg_vector=0x5dce628) at eval.c:3207 #10 0x007b9e7d in funcall_general (fun=XIL(0xa000000009136058), numargs=10, args=0x5dce628) at eval.c:2972 #11 0x007ba202 in Ffuncall (nargs=11, args=0x5dce620) at eval.c:3022 #12 0x007b90d0 in Fapply (nargs=2, args=0x9d14648) at eval.c:2693 #13 0x007ba9ab in funcall_subr (subr=0xdc1f40 , numargs=2, args=0x9d14648) at eval.c:3113 #14 0x0082d5b7 in exec_byte_code (fun=XIL(0xa000000009108c20), args_template=513, nargs=2, args=0x9d145e8) at bytecode.c:815 #15 0x007baafa in fetch_and_exec_byte_code (fun=XIL(0xa00000000a6685e0), args_template=0, nargs=0, args=0x5dcee70) at eval.c:3135 #16 0x007bb059 in funcall_lambda (fun=XIL(0xa00000000a6685e0), nargs=0, arg_vector=0x5dcee70) at eval.c:3207 #17 0x007b9e7d in funcall_general (fun=XIL(0xa00000000a6685e0), numargs=0, args=0x5dcee70) at eval.c:2972 #18 0x007ba202 in Ffuncall (nargs=1, args=0x5dcee68) at eval.c:3022 #19 0x007adffe in call0 (fn=XIL(0xa00000000a6685e0)) at lisp.h:3349 #20 0x007b397d in Fhandler_bind_1 (nargs=3, args=0x9d14478) at eval.c:1403 #21 0x007ba9ab in funcall_subr (subr=0xdc1dc0 , numargs=3, args=0x9d14478) at eval.c:3113 #22 0x0082d5b7 in exec_byte_code (fun=XIL(0xa000000009041ed0), args_template=257, nargs=1, args=0x9d14440) at bytecode.c:815 #23 0x007baafa in fetch_and_exec_byte_code (fun=XIL(0xa000000009365d18), args_template=0, nargs=0, args=0x5dcf5a0) at eval.c:3135 #24 0x007bb059 in funcall_lambda (fun=XIL(0xa000000009365d18), nargs=0, arg_vector=0x5dcf5a0) at eval.c:3207 #25 0x007baca9 in apply_lambda (fun=XIL(0xa000000009365d18), args=XIL(0), count=128) at eval.c:3157 #26 0x007b85e6 in eval_sub (form=XIL(0xc00000000982c7b0)) at eval.c:2572 #27 0x007b75b9 in Feval (form=XIL(0xc00000000982c7b0), lexical=XIL(0x30)) at eval.c:2389 #28 0x006b01ec in top_level_2 () at keyboard.c:1173 #29 0x007b4530 in internal_condition_case (bfun=0x6b0163 , handlers=XIL(0x90), hfun=0x6af6c2 ) at eval.c:1537 #30 0x006b027f in top_level_1 (ignore=XIL(0)) at keyboard.c:1185 #31 0x007b319e in internal_catch (tag=XIL(0x10a40), func=0x6b020b , arg=XIL(0)) at eval.c:1217 #32 0x006b0056 in command_loop () at keyboard.c:1134 #33 0x006af122 in recursive_edit_1 () at keyboard.c:744 #34 0x006af3c0 in Frecursive_edit () at keyboard.c:827 #35 0x006aa3cc in main (argc=15, argv=0x77a2970) at emacs.c:2624 Lisp Backtrace: "charset-after" (0x9d14a08) "fill-move-to-break-point" (0x9d149b8) "fill-region-as-paragraph" (0x9d14948) "fill-region" (0x9d14898) "easy-mmode--mode-docstring" (0x9d14778) 0x9136058 PVEC_COMPILED "apply" (0x9d14648) "macroexpand-1" (0x9d145d8) "macroexp-macroexpand" (0x9d14578) "byte-compile-recurse-toplevel" (0x9d14538) "byte-compile-toplevel-file-form" (0x9d144f0) 0xa6685a8 PVEC_COMPILED 0xa6685e0 PVEC_COMPILED "handler-bind-1" (0x9d14478) 0x9041ed0 PVEC_COMPILED "bytecomp--displaying-warnings" (0x9d14390) "byte-compile-from-buffer" (0x9d14328) "byte-compile-file" (0x9d14288) "batch-byte-compile-file" (0x9d14228) "batch-byte-compile" (0x9d14198) "command-line-1" (0x9d140b8) "command-line" (0x9d14048) "normal-top-level" (0x5dcf5a0) (gdb) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 19:01:08 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 00:01:08 +0000 Received: from localhost ([127.0.0.1]:46866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSnB6-0005xt-CR for submit@debbugs.gnu.org; Wed, 24 Jan 2024 19:01:08 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSnB4-0005xB-AO for 68690@debbugs.gnu.org; Wed, 24 Jan 2024 19:01:06 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EB31210007D; Wed, 24 Jan 2024 19:00:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706140854; bh=YzpWuVbqt+4psiyRQK3agtPh6AvKNYlNrzgiO+B92AE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CoM3/toekobXuV7b/MSYDCWnMJInwXDJXB6a65MNfCAfPmh/+8SCCQp08sSBKzVJB inDV6KKh3pNCuM2ddOYCNZsmcwlNaVbOGSmkV8jxzoTHcN6QGqS1ut36G4WL08kjAX z+c3OwODWc6bo8K9vTfWJCHOTgnCXI5xVnYnBcoM+YBcpVKgkNtp30ur6RAgZewXkG ZI0/Cgu2X/azKD/5UxQC0YK70hrpEMqxaddIyM6WDMGNWZJ/eiKx2IsZ5nJUNFpmVD hyR9Ih1uLX6FklljPRUGhZ10ApBlhk80iAXOH92L5IjeU9zE7uTuq7waLIWe1FL1FJ dyhWyJCVan8/A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F35AE10001D; Wed, 24 Jan 2024 19:00:53 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E359912082A; Wed, 24 Jan 2024 19:00:53 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86sf2mcwa2.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Jan 2024 22:27:01 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> Date: Wed, 24 Jan 2024 18:59:44 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.245 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The build now crashes here (this is a 32-bit build with large ints): > > '../src/bootstrap-emacs.exe' -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--inhibit-version-check t)" \ > -l bytecomp -f byte-compile-refresh-preloaded \ > -f batch-byte-compile ../lisp/mwheel.el > > lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) > > Here's the backtrace from GDB: > > lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) > > Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, > backtrace_limit=2147483647) at emacs.c:442 > 442 signal (sig, SIG_DFL); > (gdb) bt > #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 > #1 0x00772401 in die (msg=0xddc80d "VECTORLIKEP (a)", > file=0xddc740 "lisp.h", line=1784) at alloc.c:8062 > #2 0x00626a44 in XVECTOR (a=XIL(0x92348b000000000)) at lisp.h:1784 > #3 0x00626ace in gc_asize (array=XIL(0x92348b000000000)) at lisp.h:1800 > #4 0x00626bba in AREF (array=XIL(0x92348b000000000), idx=1) at lisp.h:1971 > #5 0x0063174d in Fcharset_after (pos=make_fixnum(113)) at charset.c:2084 Hmm... I can't reproduce it here (even with native-comp and `--with-wide-int`). The above stack frame suggests it might be related to commit 33b8d5b6c5a (and hence unrelated to the original bug#68690 which was a bug in `DOHASH`). Any chance you can investigate what is this `0x92348b000000000`? It should be a charset's attributes and the "idx=1" is because we're using `CHARSET_ATTR_NAME` to extract the name. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 00:33:35 2024 Received: (at submit) by debbugs.gnu.org; 25 Jan 2024 05:33:35 +0000 Received: from localhost ([127.0.0.1]:47080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSsMo-0003uo-KL for submit@debbugs.gnu.org; Thu, 25 Jan 2024 00:33:34 -0500 Received: from lists.gnu.org ([2001:470:142::17]:57696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSsMm-0003ua-R5 for submit@debbugs.gnu.org; Thu, 25 Jan 2024 00:33:33 -0500 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 1rSsMV-00043N-Hj for bug-gnu-emacs@gnu.org; Thu, 25 Jan 2024 00:33:20 -0500 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rSsMT-00064R-Qn; Thu, 25 Jan 2024 00:33:15 -0500 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2cd33336b32so84505881fa.0; Wed, 24 Jan 2024 21:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706160790; x=1706765590; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=4sY3Zzg8Tg8KHgJuFqc7C6SfYGOEisnFY17wU5x/o1k=; b=QYn9W52ZUcNmEF/+ESIgVOpCq9YTfn1Mcs/nOFLwlXFuAvLTUqrcu0CXG79mz4Ss7c yzEbPfH31GTLO4mUXZtwMI1e5qdxuTRhgz0SuK3nNWgCukZgMhskpgT9fdEyeBAYecLm ahRgO4rKgce/4d+RwK+u86N3qhJiI6O8VsYk5Pdpzo56IMjN8yzIuF7nEvLsQHOSkZno mIGpEXYM8V83y30g6p7DIoNdwQuxNSfLN5U/GwcKIzTrHaQH6SxwxlqhsFdxxvpl2SDD Iq1EakZz+/XbZ+FZVubB09QXuUR1N4P2YpCJByjoWkrEZZ0lyhEYMxbeH3t77ytvRQMH 0Cog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706160790; x=1706765590; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4sY3Zzg8Tg8KHgJuFqc7C6SfYGOEisnFY17wU5x/o1k=; b=CybJ7c954J7PT+GY3RYQyDMmn+PmHviEyk5C1rHWDj2eUFePluQNG596e8k47XrIds J5zeonzLuMGE+rnsbRRm+LZZ4YLd14uErztyVTjvQqiGS1jNKXWiBOPOkHXLtq+AETwc 68bYeaKb70UTYwLOniHLDmFzDsb3ue+XJglNd09wdfmhrIsjhwOZxLzGn6jOb0M4GHM3 OQ5cLGX94a6FvcXB7/2koiDREDDVD/sv7md0+Yl1n4zPoPbOUVQOegM7oPdetrQ+laAS YGT5s92r/89gC/ODvRH3xV3JHnswVZAzyAvmylGxrRRWhdR1ewRZ+AFPBJadkNqPpXw0 i0uQ== X-Gm-Message-State: AOJu0YxDtV7C+qkXdDbAnJGnZFh8wWR06YTCiB2D4WUg4XGgQ6o0JOzu vo7xxhCtqPzqIf0fnxxxmwwmqP5BqG/sNbGlga0aF12AjpUc1xLhoz0ADwXr X-Google-Smtp-Source: AGHT+IGW+v8xVzR2++wh9W9CoTBGTRyPPpaN0xHZsGcTsG9Uh423rWD0wPCuKG/mvr3u6ayIE5wjTg== X-Received: by 2002:a05:6512:200d:b0:50e:abe1:1c3c with SMTP id a13-20020a056512200d00b0050eabe11c3cmr169369lfb.98.1706160789896; Wed, 24 Jan 2024 21:33:09 -0800 (PST) Received: from Pro.fritz.box (pd9e362e3.dip0.t-ipconnect.de. [217.227.98.227]) by smtp.gmail.com with ESMTPSA id o18-20020a1709061d5200b00a26f1f36708sm620819ejh.78.2024.01.24.21.33.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 21:33:09 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: (Stefan Monnier via's message of "Wed, 24 Jan 2024 14:56:49 -0500") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> Date: Thu, 25 Jan 2024 06:33:08 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::22b; envelope-from=gerd.moellmann@gmail.com; helo=mail-lj1-x22b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , john muhl , 68690@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: >> Adding Stefan, who installed that commit. > > Oops, should be fixed now, > I wonder if a puthash while being in a DOHASH (which is the ASAN failure I showed) is something we should pursue. I don't think that's something that's guaranteed to work in a meaningful way. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 03:34:02 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 08:34:02 +0000 Received: from localhost ([127.0.0.1]:47260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSvBR-00063C-Hn for submit@debbugs.gnu.org; Thu, 25 Jan 2024 03:34:02 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:44517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSvBP-00062s-0s for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 03:33:59 -0500 Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a30ed6dbdadso220727666b.1 for <68690@debbugs.gnu.org>; Thu, 25 Jan 2024 00:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706171627; x=1706776427; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hXQS08XJb+q9uSqdIW+3nQ0ffqLsTFI9+5u5Lan/iko=; b=mZHNEv37ElbDq6SfXLeQuKQtfc+qcGlRJ6+5DmsSeTR+Vh0cfvLnOQTFfiGkxeS8Qz kBomfsZnNly5cD6JhehpLLuR3o3vCrJKKsxNkpVEhTjIfklO1w52ApWozChLtclJ152t CE8z7k8yKvP6dYt2RNdOAsvWoH+nPSNeGd4DayracwCwd6ookPdXBfGwW6CUgxqVGDq7 8RmSFc2vs+z7/g4sXKtE6HxHfbOiVE4xin6s8z3I7OjTHAb7+4KqZ5ioRTe+evFPIGNh pmpR81xHzg/mNirbQf0zSdcZKIKyWih+U8zBSXcY+dNKmPp7Fh9X3JqWYL2WHN5DxcSR tmBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706171627; x=1706776427; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hXQS08XJb+q9uSqdIW+3nQ0ffqLsTFI9+5u5Lan/iko=; b=rYzJcXnN/ztJbLp03bA3yHsC8EbvYp7L8duXMkQ98G/nu9e11QiH15wVVYRSobDIaF I1sfI9t1kuOCKAqNWnU/Dh7u9YveFWDtigzt441V0z4wwiFs0rG+29BvcjIkfX5yYVvO vOonwS2aCNTkBp/ryEUg4G3Xj4jUnEEPm7tM2wG1gESO0fhMJx8byhIeD0MPQPDmUsNL EXM+V/k4itFjWWnMn76ogSLf1yzg+9zZwiJ22/FaCwrRNaCPlQlzUAsSrsh5kd0hpQnQ KbkYXho5KNOF+jSIA9+R2/P0U9DbfrjU4/GX7NzutWMUEVVD4z7SPTcMA4Q+oIEGv0NX /VHw== X-Gm-Message-State: AOJu0Yy1vlE1eRlyrz62UL/Wv78vaMJTNw0PZyzbYhZhom6x0qvSZaP0 gxCChsmy/M1K7U0OVy/Kxe+EnleEtLs5Ok1DvHDGQ++nh4Mg993j X-Google-Smtp-Source: AGHT+IE02Tav4gW4oZYrqE2hf8d9lgFfg20Sxi28v7H3DR5o/m+vc+TcM5DQXWTW4/gcwNHLvB3jIw== X-Received: by 2002:a17:906:4091:b0:a27:7cc5:b019 with SMTP id u17-20020a170906409100b00a277cc5b019mr305955ejj.92.1706171627149; Thu, 25 Jan 2024 00:33:47 -0800 (PST) Received: from Pro.fritz.box (pd9e362e3.dip0.t-ipconnect.de. [217.227.98.227]) by smtp.gmail.com with ESMTPSA id kt12-20020a170906aacc00b00a2b3bb73b83sm771767ejb.94.2024.01.25.00.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 00:33:46 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: 68690@debbugs.gnu.org Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann?= =?utf-8?Q?=22's?= message of "Thu, 25 Jan 2024 06:33:08 +0100") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> Date: Thu, 25 Jan 2024 09:33:45 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68690 Cc: eliz@gnu.org, jm@pub.pink, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >>> Adding Stefan, who installed that commit. >> >> Oops, should be fixed now, >> > > I wonder if a puthash while being in a DOHASH (which is the ASAN failure > I showed) is something we should pursue. I don't think that's something > that's guaranteed to work in a meaningful way. WDYT? BTW, I'm using the code below for CL packages, which have a hash table. A bit less hideous ;-). /* Iterator for hash tables. */ struct h_iter { /* Hash table being iterated over. */ const struct Lisp_Hash_Table *h; /* Current index in key/value vector of H. */ ptrdiff_t i; /* Key and value at I, or nil. */ Lisp_Object key, value; }; /* Return a freshly initialized iterator for iterating over hash table TABLE. */ static struct h_iter h_init (Lisp_Object table) { struct Lisp_Hash_Table *h =3D check_hash_table (table); struct h_iter it =3D {.h =3D h, .i =3D 0, .key =3D Qnil, .value =3D Qnil}; return it; } /* Value is true if iterator IT is on a valid poisition. If it is, IT->key and IT->value are set to key and value at that position. */ static bool h_valid (struct h_iter *it) { for (; it->i < HASH_TABLE_SIZE (it->h); ++it->i) if (!hash_unused_entry_key_p (HASH_KEY (it->h, it->i))) { it->key =3D HASH_KEY (it->h, it->i); it->value =3D HASH_VALUE (it->h, it->i); return true; } return false; } /* Advance to next element. */ static void h_next (struct h_iter *it) { ++it->i; } /* Macrology. IT is a variable name that is bound to an iterator over hash table TABLE for the duration of the loop. */ #define FOR_EACH_KEY_VALUE(it, table) \ for (struct h_iter it =3D h_init (table); h_valid (&it); h_next (&it)) From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 05:27:10 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 10:27:10 +0000 Received: from localhost ([127.0.0.1]:47391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSwwv-0000hE-K2 for submit@debbugs.gnu.org; Thu, 25 Jan 2024 05:27:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSwwq-0000gg-Ij for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 05:27:07 -0500 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 1rSwwe-0004Lc-Jv; Thu, 25 Jan 2024 05:26:52 -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=+wLJObSjGAsQxRk9I4dQBGAevjqh+po2LR3SyElU3Uk=; b=g5Mx7Yy7AVld nHpuaesdJ0CJGDJVL4aALhnd4WIsb0a+vMWQn5jAbbrPjMYCTcMUwo19HKNh49iTm3pKYgZz53Whh 6gSrs4e3h3AY6ljIMwJKjJWueztlK2FFlcnpWCi/AopCV+2Ej1dovde9fAuElZvr3MWKSOZL8Ary0 XJmrJm3N8KVtFXEoHgb0CXs6wx7ox2HdtKjRK1xBJz/kuD334bF1VFXPIfThI+q8LFPSJ3rc205aC rR+Tf7eX+BoZQEf3pTZaw+3mQl1LX0BLe1ocdQixA7tCyD97TvcPAbEW8864WTZj3X+RYEBZj6EE7 Bz8DyrmIIeGMSO91Rtj37g==; Date: Thu, 25 Jan 2024 12:26:29 +0200 Message-Id: <86le8dd7ze.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 24 Jan 2024 18:59:44 -0500) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: jm@pub.pink, 68690@debbugs.gnu.org > Date: Wed, 24 Jan 2024 18:59:44 -0500 > > > Here's the backtrace from GDB: > > > > lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) > > > > Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, > > backtrace_limit=2147483647) at emacs.c:442 > > 442 signal (sig, SIG_DFL); > > (gdb) bt > > #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 > > #1 0x00772401 in die (msg=0xddc80d "VECTORLIKEP (a)", > > file=0xddc740 "lisp.h", line=1784) at alloc.c:8062 > > #2 0x00626a44 in XVECTOR (a=XIL(0x92348b000000000)) at lisp.h:1784 > > #3 0x00626ace in gc_asize (array=XIL(0x92348b000000000)) at lisp.h:1800 > > #4 0x00626bba in AREF (array=XIL(0x92348b000000000), idx=1) at lisp.h:1971 > > #5 0x0063174d in Fcharset_after (pos=make_fixnum(113)) at charset.c:2084 > > Hmm... I can't reproduce it here (even with native-comp and > `--with-wide-int`). This build is without native-comp, but it's a 32-bit build. Did you try that? I think that's the key to unlock this (see below). > The above stack frame suggests it might be related > to commit 33b8d5b6c5a (and hence unrelated to the original bug#68690 > which was a bug in `DOHASH`). > > Any chance you can investigate what is this `0x92348b000000000`? It's obviously a bogus value, since Lisp objects in this build should have their high 32 bits zero except for the type tag in the MSBs. > It should be a charset's attributes and the "idx=1" is because > we're using `CHARSET_ATTR_NAME` to extract the name. It sounds like we are not dumping the charset attributes correctly, and that also corrupts all the fields of a struct charset following the attributes. Here's this charset in temacs: Thread 1 hit Breakpoint 2, dump_charset (ctx=0x5f6dad0, cs_i=0) at pdumper.c:3224 3224 dump_field_lv (ctx, &out, cs, &cs->attributes, WEIGHT_NORMAL); (gdb) p cs $1 = (const struct charset *) 0x1050de0 (gdb) p *cs $2 = { id = 0, attributes = XIL(0xa000000009023d88), dimension = 1, code_space = {0, 127, 128, 128, 0, 0, 1, 128, 0, 0, 1, 128, 0, 0, 1}, code_space_mask = 0x0, code_linear_p = 1, iso_chars_96 = 0, ascii_compatible_p = 1, supplementary_p = 0, compact_codes_p = 1, unified_p = 0, iso_final = 66, iso_revision = -1, emacs_mule_id = 0, method = CHARSET_METHOD_OFFSET, min_code = 0, max_code = 127, char_index_offset = 0, min_char = 0, max_char = 127, invalid_code = 128, fast_map = "\001", '\000' , code_offset = 0 } (gdb) p cs->attributes $3 = XIL(0xa000000009023d88) (gdb) xtype Lisp_Vectorlike PVEC_NORMAL_VECTOR (gdb) xvector $4 = (struct Lisp_Vector *) 0x9023d88 {make_fixnum(0), XIL(0x2ca0), XIL(0xc0000000091014e0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0)} (gdb) p AREF(cs->attributes,1) $5 = 11424 (gdb) xtype Lisp_Symbol (gdb) xsymbol $6 = (struct Lisp_Symbol *) 0x10beda0 "ascii" Looks entirely reasonable, and is the ASCII charset (makes sense since the ID is zero). And here's the same charset in emacs, after we restore from dump: #5 0x0063174d in Fcharset_after (pos=make_fixnum(113)) at charset.c:2084 2084 return (CHARSET_NAME (charset)); (gdb) p charset $1 = (struct charset *) 0x9100064 (gdb) p *charset $2 = { id = 0, attributes = XIL(0x92848b000000000), dimension = -1610612736, code_space = {1, 0, 127, 128, 128, 0, 0, 1, 128, 0, 0, 1, 128, 0, 0}, code_space_mask = 0x1 , code_linear_p = 0, iso_chars_96 = 0, ascii_compatible_p = 0, supplementary_p = 0, compact_codes_p = 0, unified_p = 0, iso_final = 21, iso_revision = 66, emacs_mule_id = -1, method = CHARSET_METHOD_OFFSET, min_code = 0, max_code = 0, char_index_offset = 127, min_char = 0, max_char = 0, invalid_code = 127, fast_map = "\200\000\000\000\001", '\000' , code_offset = 0 } Note that the attributes are bogus (zero-extended on the right to 64 bits), and all the fields after that are shifted (by 32 bits, I'm guessing). So I think we fail to dump the attributes, and my guess is that this is related to the fact that in this build a pointer is 32-bit wide, but a Lisp object is a 64-bit data type. I tried to figure out what is wrong with how we dump this new field, but got lost in the proverbial twisty little passages of pdumper.c, all alike. For example, I cannot understand why some fields which are Lisp objects are dumped with dump_field_lv while others with dump_field_lv_or_rawptr, and what is the significance of WEIGHT_NORMAL vs WEIGHT_STRONG. Hopefully, the above gives enough information for you to figure this out. TIA From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 10:58:19 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 15:58:19 +0000 Received: from localhost ([127.0.0.1]:48933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT27P-0006vp-1q for submit@debbugs.gnu.org; Thu, 25 Jan 2024 10:58:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT27N-0006va-0s for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 10:58:17 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B8BFA4427F1; Thu, 25 Jan 2024 10:58:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706198284; bh=dlqjgGS1Asf1GF8eyI3fV+JKT4iA4dORjgwbmSFmYds=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mticxHDMmk8LmF8ggrQ+d5a5wdCfDG0fgwV43FoqToFqIoO/ovqcEMhTYQ7lbY3fx tOOfiTbdmsEf8vinGjQS7vg43mODTlWzyXc5UOP+Xt8VMGOxn0XA3xqbKmtIZrW2Bi 9jFvZzunGHfEp7lanTydhIuYI4RBkuAISbwcSqJgjAfg8M5mOlI0qQTlL/xqAlWaAj 7/HwCxg+mpDvquMJU5y+EPGGpFs8ryGGD8CaOW9CEgXLqhSGkjWfHLnBKnTvZrpcs/ okhyshsHFhleEDiwOgm0vsqXWdzepG1o1xVN+1h5bOU1WjT+iqZWREzNSsktxbx8Z/ 5qb//FeHWcmiA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 94C2B4427E6; Thu, 25 Jan 2024 10:58:04 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 673091208CC; Thu, 25 Jan 2024 10:58:04 -0500 (EST) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: ("Gerd =?windows-1252?Q?M=F6ll?= =?windows-1252?Q?mann=22's?= message of "Thu, 25 Jan 2024 09:33:45 +0100") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> Date: Thu, 25 Jan 2024 10:58:03 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: eliz@gnu.org, jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I wonder if a puthash while being in a DOHASH (which is the ASAN failure >> I showed) is something we should pursue. I don't think that's something >> that's guaranteed to work in a meaningful way. WDYT? The original DOHASH's comment indeed said it didn't support that operation, yet the code used DOHASH to implement `maphash`, which *does* support such operations, and it used DOHASH in places which perform such operations, so I think it's clear we do want to support `puthash` there. > BTW, I'm using the code below for CL packages, which have a hash table. > A bit less hideous ;-) Nice. The motivation for the change from `DOHASH (h, i)` to `DOHASH (h, k, v)` was not only to offer cleaner code but also to avoid reloading `h->key_and_value` and `h->table_size` at every iteration (`h->key_and_value` is particularly annoying because it's on the critical path to load `key` and `value`). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 13:12:40 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 18:12:40 +0000 Received: from localhost ([127.0.0.1]:49154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT4DQ-00057U-ED for submit@debbugs.gnu.org; Thu, 25 Jan 2024 13:12:40 -0500 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]:55634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT4DL-00057D-3J for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 13:12:38 -0500 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5100cb238bcso4610745e87.3 for <68690@debbugs.gnu.org>; Thu, 25 Jan 2024 10:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706206343; x=1706811143; darn=debbugs.gnu.org; h=to:cc:date:message-id:subject:mime-version:from:sender:from:to:cc :subject:date:message-id:reply-to; bh=Wdr/3BCg5gVsQO9HRLNYEDqgAbdevH0rCpigXhnmLws=; b=dU9ysl2Lf0yZG6bzGyLdI3w49TJ5ZZeB6BLwBM1Boaa+Kqk6fPQxoKu7tbJDB/xxts O5Cu1zgRi1o8O8YMqv/bnG2ZwafNq5JND/ftfmCKQdON1NyQ0SCJCrCki/iaHtrYlnYq EVN51sUj/U20QJa7EJpLBVqWQYdca9cHFRiNZnN3I2wpSOAKciwXqCLxb8Nyxt+XhbYP J1op4SZKCyIUJr8DIJZj+KXcp3jioSWKsAFLOZiGJJe17U5w8MClrFEIVZX390pp84Dk cci8eIu/tnwFxdCLNfZ3FR7SrkOrU1ovOjdYmgg511wsEJUNw6RJZjdXpMBKw0uSPdQo L8AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706206343; x=1706811143; h=to:cc:date:message-id:subject:mime-version:from:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Wdr/3BCg5gVsQO9HRLNYEDqgAbdevH0rCpigXhnmLws=; b=GIpBJOqT7pzh88G/oeqlAbmt6I4ez2EjMvbDGQC2K+SmqeI8ZZ8DdO/vmSGUHUVTTz kuGIVYkQ5f7ro4a4z03FdnY5htKKHh9Y4DLaMvTNFGfCn9rOFN9TPKgmywKYc/diYxBE czcrAKVzU9o6GBEdJD+53h3fvBXtIMI0Uw9k7u1b7MlEmn3qI8RssAQBtT5Qy+VL2re5 Mf3eSr3tWPzRXuV5KsiBCymfmdKAhgURVaPG5CXGX/snwXU1aocX5zCDtvIv5JbXfYoj PV3ed/4CdSHSi/s0jH2z3q1GwAO7AjPkdVgoI3r1BUhqsV9dXElNB3bnRu6RTlfo58np EBeA== X-Gm-Message-State: AOJu0YwKi2/ck4egXizc643+kFI4YVWAz6tpiqwxxpXrHbXuE3EC4Ont /DSKSXzn+e4T0BYsw+DDDe6kOhqPUNnL3ZhhSFnmZbWqIpcAZGLE X-Google-Smtp-Source: AGHT+IFEJH8xFtx8b2qNO4OA+tl9hSJdStTiFJxfRYYyTLj6P3c6zb5PpvSPCn2rNUR37OUi8BQYXQ== X-Received: by 2002:ac2:4555:0:b0:510:141b:4f94 with SMTP id j21-20020ac24555000000b00510141b4f94mr83968lfm.52.1706206342857; Thu, 25 Jan 2024 10:12:22 -0800 (PST) Received: from smtpclient.apple (c80-217-1-132.bredband.tele2.se. [80.217.1.132]) by smtp.gmail.com with ESMTPSA id r21-20020ac25f95000000b005101e485d34sm182410lfe.148.2024.01.25.10.12.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2024 10:12:22 -0800 (PST) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: multipart/mixed; boundary="Apple-Mail=_E4AF28AF-DD4F-4C24-82A1-E0560B4E0C28" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: bug#68690: Segmentation fault building with native-comp Message-Id: Date: Thu, 25 Jan 2024 19:12:21 +0100 To: Stefan Monnier X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68690 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --Apple-Mail=_E4AF28AF-DD4F-4C24-82A1-E0560B4E0C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The original DOHASH's comment indeed said it didn't support that > operation, yet the code used DOHASH to implement `maphash`, which = *does* > support such operations, and it used DOHASH in places which perform = such > operations, so I think it's clear we do want to support `puthash` = there. Sorry, my fault -- indeed maphash 'supports' irregular mutation in the = sense that it shouldn't crash or corrupt Emacs if the rules are = violated. I can't reproduce the reported crash(es) on my platform but is = my understanding correct that no other uses of DOHASH caused any = trouble? This patch reverts my last change to Fmaphash and yours to DOHASH. It's = perfectly fine to forego DOHASH in Fmaphash, it's chums with the = hash-table implementation. Assuming that the problems were confined to = Fmaphash, this should be safe to apply. What I certainly would accept is an assertion in DOHASH that verifies = the assumptions but doesn't result in any code at all with checking = disabled. I'll add that if you think it's warranted (and maybe even if = you don't). --Apple-Mail=_E4AF28AF-DD4F-4C24-82A1-E0560B4E0C28 Content-Disposition: attachment; filename=0001-Revert-to-fast-and-simple-DOHASH-keeping-Fmaphash-ro.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Revert-to-fast-and-simple-DOHASH-keeping-Fmaphash-ro.patch" Content-Transfer-Encoding: quoted-printable =46rom=201b44dc419c55cba7e41e8fd8376ebfbae12f04e4=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20= =0ADate:=20Thu,=2025=20Jan=202024=2018:56:03=20+0100=0A= Subject:=20[PATCH]=20Revert=20to=20fast=20and=20simple=20DOHASH=20= keeping=20Fmaphash=20robust=0A=20(bug#68690)=0A=0A`maphash`=20mustn't=20= crash=20if=20the=20supplied=20function=20does=20odd=20things=20but=0A= that=20doesn't=20mean=20we=20have=20to=20make=20DOHASH=20more=20= expensive.=0AThis=20change=20essentially=20reverts=20ad004f10f3=20and=20= the=20Fmaphash=20part=20of=0Afec87a4b36.=0A=0A*=20src/lisp.h=20(DOHASH):=20= Go=20back=20to=20fast=20design=20with=20more=20rules.=0A*=20src/fns.c=20= (Fmaphash):=20Ditch=20DOHASH=20in=20favour=20of=20explicit=20loop.=0A---=0A= =20src/fns.c=20=20|=2011=20+++++++++--=0A=20src/lisp.h=20|=2038=20= ++++++++++++++------------------------=0A=202=20files=20changed,=2023=20= insertions(+),=2026=20deletions(-)=0A=0Adiff=20--git=20a/src/fns.c=20= b/src/fns.c=0Aindex=20859df6748f7..519d85df288=20100644=0A---=20= a/src/fns.c=0A+++=20b/src/fns.c=0A@@=20-5662,8=20+5662,15=20@@=20DEFUN=20= ("maphash",=20Fmaphash,=20Smaphash,=202,=202,=200,=0A=20=20=20= (Lisp_Object=20function,=20Lisp_Object=20table)=0A=20{=0A=20=20=20struct=20= Lisp_Hash_Table=20*h=20=3D=20check_hash_table=20(table);=0A-=20=20DOHASH=20= (h,=20k,=20v)=0A-=20=20=20=20call2=20(function,=20k,=20v);=0A+=20=20/*=20= We=20can't=20use=20DOHASH=20here=20since=20FUNCTION=20may=20violate=20= the=20rules=20and=0A+=20=20=20=20=20we=20shouldn't=20crash=20as=20a=20= result=20(although=20the=20effects=20are=0A+=20=20=20=20=20= unpredictable).=20=20*/=0A+=20=20for=20(ptrdiff_t=20i=20=3D=200;=20i=20<=20= HASH_TABLE_SIZE=20(h);=20i++)=0A+=20=20=20=20{=0A+=20=20=20=20=20=20= Lisp_Object=20k=20=3D=20HASH_KEY=20(h,=20i);=0A+=20=20=20=20=20=20if=20= (!hash_unused_entry_key_p=20(k))=0A+=20=20=20=20=20=20=20=20call2=20= (function,=20k,=20HASH_VALUE=20(h,=20i));=0A+=20=20=20=20}=0A=20=20=20= return=20Qnil;=0A=20}=0A=20=0Adiff=20--git=20a/src/lisp.h=20b/src/lisp.h=0A= index=20d07d9d14e2f..f822417ffb1=20100644=0A---=20a/src/lisp.h=0A+++=20= b/src/lisp.h=0A@@=20-2604,30=20+2604,20=20@@=20hash_from_key=20(struct=20= Lisp_Hash_Table=20*h,=20Lisp_Object=20key)=0A=20}=0A=20=0A=20/*=20= Iterate=20K=20and=20V=20as=20key=20and=20value=20of=20valid=20entries=20= in=20hash=20table=20H.=0A-=20=20=20The=20body=20may=20mutate=20the=20= hash-table.=20=20*/=0A-#define=20DOHASH(h,=20k,=20v)=09=09=09=09=09=09=09= =20\=0A-=20=20for=20(Lisp_Object=20*dohash_##k##_##v##_base=20=3D=20= (h)->key_and_value,=09=20\=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20*dohash_##k##_##v##_kv=20=20=20=3D=20= dohash_##k##_##v##_base,=09=20\=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20*dohash_##k##_##v##_end=20=20=3D=20= dohash_##k##_##v##_base=09=20\=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20+=202=20*=20HASH_TABLE_SIZE=20(h),=20\=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20k,=20v;=09=09=09=09=09=09= =20\=0A-=20=20=20=20=20=20=20dohash_##k##_##v##_kv=20<=20= dohash_##k##_##v##_end=09=09=09=20\=0A-=20=20=20=20=20=20=20&&=20= (dohash_##k##_##v##_base=20=3D=3D=20(h)->key_and_value=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20=20=20/*=20= The=20`key_and_value`=20table=20has=20been=20reallocated!=20=20*/=20=20=20= =20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20=20=20||=20= (dohash_##k##_##v##_kv=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20= (dohash_##k##_##v##_kv=20-=20dohash_##k##_##v##_base)=09=20\=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+=20= (h)->key_and_value,=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20dohash_##k##_##v##_base=20=3D=20(h)->key_and_value,=20=20= =20=20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20dohash_##k##_##v##_end=20=20=3D=20dohash_##k##_##v##_base=09=20= \=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20+=202=20*=20= HASH_TABLE_SIZE=20(h),=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20/*=20Check=20again,=20in=20case=20the=20table=20has=20= shrunk.=20=20*/=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20dohash_##k##_##v##_kv=20<=20dohash_##k##_##v##_end))=20= =20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20&&=20(k=20=3D=20= dohash_##k##_##v##_kv[0],=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20= =20=20=20=20=20v=20=3D=20dohash_##k##_##v##_kv[1],=20/*maybe=20unused*/=20= (void)v,=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20=20=20=20= true);=09=09=09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20\=0A-=20=20=20=20=20=20=20=20= dohash_##k##_##v##_kv=20+=3D=202)=09=09=09=09=20=20=20=20=20=20=20=20=20= \=0A-=20=20=20=20if=20(hash_unused_entry_key_p=20(k))=09=09=09=09=20=20=20= =20=20=20=20=20=20\=0A-=20=20=20=20=20=20;=09=09=09=09=09=09=09=09=20=20=20= =20=20=20=20=20=20\=0A+=20=20=20The=20body=20may=20remove=20the=20= current=20entry=20or=20alter=20its=20value=20slot,=20but=20not=0A+=20=20=20= mutate=20TABLE=20in=20any=20other=20way.=20=20*/=0A+#define=20DOHASH(h,=20= k,=20v)=09=09=09=09=09=09=09\=0A+=20=20for=20(Lisp_Object=20= *dohash_##k##_##v##_kv=20=3D=20(h)->key_and_value,=09=09\=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*dohash_##k##_##v##_end=20=3D= =20dohash_##k##_##v##_kv=09\=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20+=202=20*=20HASH_TABLE_SIZE=20(h),=09\=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20k,=20v;=09=09=09=09=09=09\=0A+=20= =20=20=20=20=20=20dohash_##k##_##v##_kv=20<=20dohash_##k##_##v##_end=09=09= =09\=0A+=20=20=20=20=20=20=20&&=20(k=20=3D=20dohash_##k##_##v##_kv[0],=09= =09=09=09\=0A+=20=20=20=20=20=20=20=20=20=20=20v=20=3D=20= dohash_##k##_##v##_kv[1],=20/*maybe=20unsed*/=20(void)v,=20=20=20=20=20=20= =20\=0A+=20=20=20=20=20=20=20=20=20=20=20true);=09=09=09=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20\=0A+=20=20=20=20=20=20=20=20dohash_##k##_##v##_kv=20+=3D=202)=09=09=09= =09=09\=0A+=20=20=20=20if=20(hash_unused_entry_key_p=20(k))=09=09=09=09=09= \=0A+=20=20=20=20=20=20;=09=09=09=09=09=09=09=09=09\=0A=20=20=20=20=20= else=0A=20=0A=20=0A--=20=0A2.32.0=20(Apple=20Git-132)=0A=0A= --Apple-Mail=_E4AF28AF-DD4F-4C24-82A1-E0560B4E0C28-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 17:39:39 2024 Received: (at 68690) by debbugs.gnu.org; 25 Jan 2024 22:39:39 +0000 Received: from localhost ([127.0.0.1]:49494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT8Nn-0003ra-GW for submit@debbugs.gnu.org; Thu, 25 Jan 2024 17:39:39 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rT8Nl-0003rF-9U for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 17:39:37 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 721FF4420FA; Thu, 25 Jan 2024 17:39:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706222364; bh=+Jo540JlrW16NJ+59wDbgz4xXhi6mfd38N/OOwbD2Nk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I9juwSgNUDYBFkEnbppByJqY2OCYdHkZqqPSGKmxnKPTJuauDfSa3fNvsE1ehmuJz HjmxnKyzAQ4LSM8gwi9O2xweDhrawKlwfDuPFUWd7qGk5Zb2NJJ7FuWQGPtpj755Yl FqNkMr/mVJXUaFIqQeBJ7N4W/ng3Jqm6vtnPQ5Q+s+ZAQo99d2trGMpyc1O5jwAmL4 2pEsJxkXA/zdrzcLhg1GAk/fcAlF/Is1HMKUzx6fW7ehg19xO7x7mQQLIi9rplz/dz TRuRBvoqZ21mEhUk9CNTT8wKjaHJXJ7w8g5jpwMa/8TWYTAhf830dT+DC3Itx8g9QB oSas5uyUvUWNA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3532E440874; Thu, 25 Jan 2024 17:39:24 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 06C30120B52; Thu, 25 Jan 2024 17:39:24 -0500 (EST) From: Stefan Monnier To: Mattias =?windows-1252?Q?Engdeg=E5rd?= Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: ("Mattias =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Thu, 25 Jan 2024 19:12:21 +0100") Message-ID: References: Date: Thu, 25 Jan 2024 17:39:23 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.017 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , Eli Zaretskii , jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Sorry, my fault -- indeed maphash 'supports' irregular mutation in the sense > that it shouldn't crash or corrupt Emacs if the rules are violated. I can't > reproduce the reported crash(es) on my platform but is my understanding > correct that no other uses of DOHASH caused any trouble? AFAIK the current DOHASH code in `master` works fine (tho a bit ugly). The remaining build failure that Eli is seeing seems unrelated. > This patch reverts my last change to Fmaphash and yours to DOHASH. It's > perfectly fine to forego DOHASH in Fmaphash, it's chums with the hash-table > implementation. Assuming that the problems were confined to Fmaphash, this > should be safe to apply. The build failure didn't come via maphash` but via the DOHASH in `comp.c` that calls `compile_function` (which apparently can cause the hash table to be resized). So `maphash` is clearly not the only "offender". Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 25 21:43:26 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 02:43:26 +0000 Received: from localhost ([127.0.0.1]:49806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTCBi-0004x0-BZ for submit@debbugs.gnu.org; Thu, 25 Jan 2024 21:43:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTCBh-0004wn-Bq for 68690@debbugs.gnu.org; Thu, 25 Jan 2024 21:43:25 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B6FB1100068; Thu, 25 Jan 2024 21:43:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706236992; bh=tKKam8J1ckJDmYaOgYVxts5eZpBSLX+C+uNgc5dxQkI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R3hXKUqOl0FMLzy/d2np6BjUDZacL4qnBzc2uo8XLjktEMc2dt2y0Oq4k/1GNNXZD JvPzEaxsvP2TAiSBoWdhx3Q1pyHXfxyIWfL2uPQAwVrAEr5teNAyItNCDltfik5dHD syh1aI87ME9TvyYhJp+5tycRuI5PADIdgcmkhEtJyRuK1y4Ars/Uhbv52blHYhdLcx 2HINiU7Z0tq4M49XVP0xHDbZStzOGbyl9qSgXoh0xjLQUAXv+099Aj3G1uodP0by3n 4e+oUwIjtCGD6Kv5rjtqFZpo2UPzQGAr1qny9t9sarJm612Nxd1dyRGLKkO9ME4dru hRH0AzZ7Dwzuw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C3D8F10004C; Thu, 25 Jan 2024 21:43:12 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8385E120BC8; Thu, 25 Jan 2024 21:43:12 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86le8dd7ze.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Jan 2024 12:26:29 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> Date: Thu, 25 Jan 2024 21:43:01 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.086 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Hmm... I can't reproduce it here (even with native-comp and >> `--with-wide-int`). > This build is without native-comp, but it's a 32-bit build. Did you > try that? I think that's the key to unlock this (see below). I tried 32bit with and without native-comp, and with and without wide-int, but can't reproduce it here. Maybe it only manifest itself under w32? In your message I see it crashes compiling `mwheel.el`; is that the first place where it crashes? Does it crash on most other files as well? In interactive use? >> The above stack frame suggests it might be related >> to commit 33b8d5b6c5a (and hence unrelated to the original bug#68690 >> which was a bug in `DOHASH`). >> Any chance you can investigate what is this `0x92348b000000000`? > It's obviously a bogus value, since Lisp objects in this build should > have their high 32 bits zero except for the type tag in the MSBs. Indeed. >> It should be a charset's attributes and the "idx=3D1" is because >> we're using `CHARSET_ATTR_NAME` to extract the name. > It sounds like we are not dumping the charset attributes correctly, > and that also corrupts all the fields of a struct charset following > the attributes. Here's this charset in temacs: [...] > (gdb) p cs->attributes > $3 =3D XIL(0xa000000009023d88) [...] > And here's the same charset in emacs, after we restore from dump: [...] > attributes =3D XIL(0x92848b000000000), Yup, sure looks like the bytes got shifted by 4 bytes for some reason. > I tried to figure out what is wrong with how we dump this new field, > but got lost in the proverbial twisty little passages of pdumper.c, > all alike. =F0=9F=99=81 > For example, I cannot understand why some fields which are > Lisp objects are dumped with dump_field_lv while others with > dump_field_lv_or_rawptr, and what is the significance of WEIGHT_NORMAL > vs WEIGHT_STRONG. Hopefully, the above gives enough information for > you to figure this out. I'm just as lost as you are in pdumper.c, sadly. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 03:41:18 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 08:41:18 +0000 Received: from localhost ([127.0.0.1]:50379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTHm1-0006sX-64 for submit@debbugs.gnu.org; Fri, 26 Jan 2024 03:41:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTHly-0006sJ-Le for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 03:41:16 -0500 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 1rTHll-0002ll-I6; Fri, 26 Jan 2024 03:41:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=X4utl6nwTvhzCHwi4mpH5U0tTsafaK1KBr0htNf7DnY=; b=CSkCu8ISjnj0O2by/T91 fVcyGP1+H6ZVrGgqUlrqTUuk4vOzDA0ttg+tD9RfJRIKzVMKHa3OOIOxWQwqdxilf325z/ADoMl/l 7THb+I9t3wfhK3DTTWtsY4zuapWBjdEniF/tZ3Xvx3nzghyG7s2FiuY5KkZUOmUNKtWZIUl3AqKQF e8PqfRmH3xHby9U4OXKzbnaGdGW45XHKmCgkYf6eU8aKhdB3wF6t0r5mlW9a4zqdDatDTXuK/sLgZ qgWikLXdoOI52x9ekI9Z+Cg32Eox1ppj1KwXq1k9pii7xwnAoKFgsX/ww921RXhuDH4tHH9nf88Yx 8wc+PCch1znGWg==; Date: Fri, 26 Jan 2024 10:40:11 +0200 Message-Id: <867cjwbi8k.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 25 Jan 2024 21:43:01 -0500) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: jm@pub.pink, 68690@debbugs.gnu.org > Date: Thu, 25 Jan 2024 21:43:01 -0500 > > >> Hmm... I can't reproduce it here (even with native-comp and > >> `--with-wide-int`). > > This build is without native-comp, but it's a 32-bit build. Did you > > try that? I think that's the key to unlock this (see below). > > I tried 32bit with and without native-comp, and with and without wide-int, > but can't reproduce it here. Maybe it only manifest itself under w32? It could be, but I cannot imagine why the way we dump charsets has anything to do with w32. > In your message I see it crashes compiling `mwheel.el`; is that the > first place where it crashes? "First place" in what sense? What happens in the build is that temacs is built and dumped to produce bootstrap-emacs, then bootstrap-emacs starts compiling Lisp files and crashes on the first one it tries to compile, with the backtrace I posted. > Does it crash on most other files as well? It seems to crash with any Lisp file I try. It also crashes in this command: '../src/emacs.exe' -batch --no-site-file --no-site-lisp \ -l ./emacs-lisp/loaddefs-gen.elc \ -f loaddefs-generate--emacs-batch . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./use-package ./vc > In interactive use? If I invoke bootstrap-emacs interactively, it crashes during startup, in window-system-initialization. The backtrace for that is below, and it again seems to show a bogus value of charset attributes. > >> The above stack frame suggests it might be related > >> to commit 33b8d5b6c5a (and hence unrelated to the original bug#68690 > >> which was a bug in `DOHASH`). > >> Any chance you can investigate what is this `0x92348b000000000`? > > It's obviously a bogus value, since Lisp objects in this build should > > have their high 32 bits zero except for the type tag in the MSBs. > > Indeed. > > >> It should be a charset's attributes and the "idx=1" is because > >> we're using `CHARSET_ATTR_NAME` to extract the name. > > It sounds like we are not dumping the charset attributes correctly, > > and that also corrupts all the fields of a struct charset following > > the attributes. Here's this charset in temacs: > [...] > > (gdb) p cs->attributes > > $3 = XIL(0xa000000009023d88) > [...] > > And here's the same charset in emacs, after we restore from dump: > [...] > > attributes = XIL(0x92848b000000000), > > Yup, sure looks like the bytes got shifted by 4 bytes for some reason. > > > I tried to figure out what is wrong with how we dump this new field, > > but got lost in the proverbial twisty little passages of pdumper.c, > > all alike. > > 🙁 > > > For example, I cannot understand why some fields which are > > Lisp objects are dumped with dump_field_lv while others with > > dump_field_lv_or_rawptr, and what is the significance of WEIGHT_NORMAL > > vs WEIGHT_STRONG. Hopefully, the above gives enough information for > > you to figure this out. > > I'm just as lost as you are in pdumper.c, sadly. Well, can I provide more info for you to try to figure out what's wrong? E.g., why and how did you decide to use dump_field_lv for dumping the charset's attributes (which is a Lisp vector)? Alternatively, any ideas for how should I proceed to debug this myself? See, I cannot afford to have the master branch be broken for me for prolonged periods of time, as that prevents me from doing my job of installing patches by others and testing various issues. We must fix this build, or face the need to revert the charset-related changes for now. Here's the backtrace during startup when bootstrap-emacs is invoked with -Q: lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 442 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:442 #1 0x00802435 in die (msg=0xe6c80d "VECTORLIKEP (a)", file=0xe6c740 "lisp.h", line=1784) at alloc.c:8062 #2 0x006b6a78 in XVECTOR (a=XIL(0x926755800000000)) at lisp.h:1784 #3 0x006b6b02 in gc_asize (array=XIL(0x926755800000000)) at lisp.h:1800 #4 0x006b6bee in AREF (array=XIL(0x926755800000000), idx=7) at lisp.h:1971 #5 0x006ba13f in map_charset_chars (c_function=0x9a7fa1 , function=XIL(0), arg=XIL(0xa000000009140a08), charset=0x91d912c, from=0, to=33) at charset.c:775 #6 0x009a9cf2 in Fset_fontset_font (fontset=XIL(0x800000000912a370), characters=XIL(0xa3e0), font_spec=XIL(0xa000000009122ed0), frame=XIL(0xa0000000090d9de8), add=XIL(0x2a90)) at fontset.c:1668 #7 0x009aa8f2 in Fnew_fontset (name=XIL(0x800000000912a370), fontlist=XIL(0xc000000005ed6570)) at fontset.c:1786 #8 0x0084a583 in funcall_subr (subr=0xe5a5c0 , numargs=2, args=0x9cd7250) at eval.c:3092 #9 0x008bd5eb in exec_byte_code (fun=XIL(0xa000000009576978), args_template=0, nargs=0, args=0x9cd7208) at bytecode.c:815 #10 0x0084ab2e in fetch_and_exec_byte_code (fun=XIL(0xa000000009279ff0), args_template=256, nargs=0, args=0x9cd7148) at eval.c:3135 #11 0x0084b08d in funcall_lambda (fun=XIL(0xa000000009279ff0), nargs=0, arg_vector=0x9cd7148) at eval.c:3207 #12 0x00849eb1 in funcall_general (fun=XIL(0xa000000009279ff0), numargs=0, args=0x9cd7148) at eval.c:2972 #13 0x0084a236 in Ffuncall (nargs=1, args=0x9cd7140) at eval.c:3022 #14 0x00848c4a in Fapply (nargs=2, args=0x9cd7140) at eval.c:2646 #15 0x0084a9df in funcall_subr (subr=0xe51f40 , numargs=2, args=0x9cd7140) at eval.c:3113 #16 0x008bd5eb in exec_byte_code (fun=XIL(0xa0000000095b4058), args_template=770, nargs=3, args=0x9cd7390) at bytecode.c:815 #17 0x0084ab2e in fetch_and_exec_byte_code (fun=XIL(0xa00000000945dc90), args_template=0, nargs=0, args=0x5e5f5a0) at eval.c:3135 #18 0x0084b08d in funcall_lambda (fun=XIL(0xa00000000945dc90), nargs=0, arg_vector=0x5e5f5a0) at eval.c:3207 #19 0x0084acdd in apply_lambda (fun=XIL(0xa00000000945dc90), args=XIL(0), count=128) at eval.c:3157 #20 0x0084861a in eval_sub (form=XIL(0xc0000000098d6248)) at eval.c:2572 #21 0x008475ed in Feval (form=XIL(0xc0000000098d6248), lexical=XIL(0x30)) at eval.c:2389 #22 0x00740220 in top_level_2 () at keyboard.c:1173 #23 0x00844564 in internal_condition_case (bfun=0x740197 , handlers=XIL(0x90), hfun=0x73f6f6 ) at eval.c:1537 #24 0x007402b3 in top_level_1 (ignore=XIL(0)) at keyboard.c:1185 #25 0x008431d2 in internal_catch (tag=XIL(0x10a40), func=0x74023f , arg=XIL(0)) at eval.c:1217 #26 0x0074008a in command_loop () at keyboard.c:1134 #27 0x0073f156 in recursive_edit_1 () at keyboard.c:744 #28 0x0073f3f4 in Frecursive_edit () at keyboard.c:827 #29 0x0073a400 in main (argc=2, argv=0x1f2570) at emacs.c:2624 Lisp Backtrace: "new-fontset" (0x9cd7250) "setup-default-fontset" (0x9cd7208) "create-default-fontset" (0x9cd71c0) 0x9279ff0 PVEC_COMPILED "apply" (0x9cd7140) "window-system-initialization" (0x9cd70b8) "command-line" (0x9cd7048) "normal-top-level" (0x5e5f5a0) (gdb) fr 5 #5 0x006ba13f in map_charset_chars (c_function=0x9a7fa1 , function=XIL(0), arg=XIL(0xa000000009140a08), charset=0x91d912c, from=0, to=33) at charset.c:775 775 for (parents = CHARSET_SUPERSET (charset); CONSP (parents); (gdb) p charset $1 = (struct charset *) 0x91d912c (gdb) p *$ $2 = { id = 0, attributes = XIL(0x926755800000000), dimension = -1610612736, code_space = {1, 33, 126, 94, 94, 0, 0, 1, 94, 0, 0, 1, 94, 0, 0}, code_space_mask = 0x1 , code_linear_p = 0, iso_chars_96 = 0, ascii_compatible_p = 0, supplementary_p = 0, compact_codes_p = 0, unified_p = 0, iso_final = 25, iso_revision = 49, emacs_mule_id = -1, method = 167, min_code = 0, max_code = 33, char_index_offset = 126, min_char = 0, max_char = 3713, invalid_code = 3806, fast_map = "\000\000\000\000\001\000\000 ", '\000' , code_offset = 0 } (gdb) From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 04:26:24 2024 Received: (at submit) by debbugs.gnu.org; 26 Jan 2024 09:26:24 +0000 Received: from localhost ([127.0.0.1]:50442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTITg-000841-A9 for submit@debbugs.gnu.org; Fri, 26 Jan 2024 04:26:24 -0500 Received: from lists.gnu.org ([2001:470:142::17]:58674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTITe-00083V-Rl for submit@debbugs.gnu.org; Fri, 26 Jan 2024 04:26:23 -0500 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 1rTITN-0007Ex-9o for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 04:26:05 -0500 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rTITL-0001R6-Pg; Fri, 26 Jan 2024 04:26:05 -0500 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a26ed1e05c7so13370966b.2; Fri, 26 Jan 2024 01:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706261161; x=1706865961; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=k3aXYfyflOUTqAyEKXPZH2GKn6CSEOrQGxj7311EhQ0=; b=J8G4w/8AfuZHeX2A2OS9I4IFcWc5pqr/lZxzBVDrFOBVm9haLVia2y89WXVNVcBpmt UGVFidcWbGh/Byhcbq+namfSGO/bFjB5CFfuF8+fxGkmSw4r6gqnUZC5U5TCFZRf45XW v8BAEebj5IAH1AlvDRsMLYFH6U32Ki8ylJ1N1UwUq4EogWophwzCcJH4vrXh8I1XFPkj z6mmTi74jhum+Mk2S6+ZsyApbyW+2UQy17edahMQyp/5KcF3iZssTHhjpdqwIXqkT9bk 9o9ib0kUBcXmG4ywDa9JOJgi6MemEhuqUsxC9RcXGJ3vu2uMpACqYSPw1iThTuZlQvTb fOTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706261161; x=1706865961; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k3aXYfyflOUTqAyEKXPZH2GKn6CSEOrQGxj7311EhQ0=; b=tszynPancxflv6tycppCEX4wnVcWNaxvyjk6FSqZLcOfLd8CcfJZ5DJZok/pU/pcik lDDKH9BPZzVJb4OWe8JrSd71jBKDbmQpwZUz1AILTkqqzefkmTkEgwEnOhFOVrUHbVpj GB6pNiF1Zc1J1sDBWDjAqynka/ICf4rFMrP2lc/5DeUHdsP2GpkuSpVhC/lX8Mo0x5kk nwyQ4zMSOnTx36AQoX3QnL52IgrYCEcn+sVM2OUI0I+qrramJGbDiWsv+AI/YV7cOit+ dt3BrOYwZJATAQ06LXdeGdCA7b4l/QnP23ipHMA8RlwZSSmkA8kNfJWFUbpvP0jxNpg6 uf4g== X-Gm-Message-State: AOJu0YxlllTBjrgiA4cc1f7xC8r3Owxxo/TwgQy0PF/9KpAoASZZN59S XQwyEJgPAQ2Q8OhVIUakLGLT7SbXB5dH8RxGaYdqwqUHOw95yyRta29ynj8G X-Google-Smtp-Source: AGHT+IH78Ve3GhxPs0781ezluzc9T0tN6Q8sJ4vo/jKYWvJyYBwdKQGj5aAmy1KR8xaBlAgBkO6Tew== X-Received: by 2002:a17:906:b2d0:b0:a27:7de8:9cd9 with SMTP id cf16-20020a170906b2d000b00a277de89cd9mr345915ejb.23.1706261161362; Fri, 26 Jan 2024 01:26:01 -0800 (PST) Received: from Pro.fritz.box (pd9e36b3f.dip0.t-ipconnect.de. [217.227.107.63]) by smtp.gmail.com with ESMTPSA id k25-20020a17090646d900b00a316490ddbbsm412060ejs.200.2024.01.26.01.26.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 01:26:00 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: (Stefan Monnier via's message of "Thu, 25 Jan 2024 21:43:01 -0500") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> Date: Fri, 26 Jan 2024 10:26:00 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x634.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , jm@pub.pink, 68690@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: >> For example, I cannot understand why some fields which are >> Lisp objects are dumped with dump_field_lv while others with >> dump_field_lv_or_rawptr, and what is the significance of WEIGHT_NORMAL >> vs WEIGHT_STRONG. Hopefully, the above gives enough information for >> you to figure this out. > > I'm just as lost as you are in pdumper.c, sadly. I remembered seeing something in pdumper.c that could be related, namely /* Start the cold section. This section contains bytes that should never change and so can be direct-mapped from the dump without special processing. */ dump_drain_cold_data (ctx); And if you follow that function you'll see that it treats charsets specially. I find the comment about directly mapping very suspicious, when the charset contains a Lisp_Object, possibly requiring relocation. But it could well be that I misundertand something here. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 05:18:44 2024 Received: (at submit) by debbugs.gnu.org; 26 Jan 2024 10:18:44 +0000 Received: from localhost ([127.0.0.1]:50503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTJIK-00012p-7y for submit@debbugs.gnu.org; Fri, 26 Jan 2024 05:18:44 -0500 Received: from lists.gnu.org ([2001:470:142::17]:47016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTJIJ-00012d-Dh for submit@debbugs.gnu.org; Fri, 26 Jan 2024 05:18:43 -0500 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 1rTJI7-0007yV-2K for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 05:18:31 -0500 Received: from mail-out.m-online.net ([2001:a60:0:28:0:1:25:1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTJI4-0007hZ-Vt; Fri, 26 Jan 2024 05:18:30 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4TLtv20S65z1sB7x; Fri, 26 Jan 2024 11:18:21 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4TLtv14d7Pz1qqlb; Fri, 26 Jan 2024 11:18:21 +0100 (CET) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id 6BvJMpQXRtGR; Fri, 26 Jan 2024 11:18:20 +0100 (CET) X-Auth-Info: lUUEI1EbzSjZtkcJBYzcpaELOxg2fzt0nIoPORA7ivUcFIE6cxBj34vxng8zcm+E Received: from igel.home (aftr-62-216-202-33.dynamic.mnet-online.de [62.216.202.33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 26 Jan 2024 11:18:20 +0100 (CET) Received: by igel.home (Postfix, from userid 1000) id 313022C1287; Fri, 26 Jan 2024 11:18:20 +0100 (CET) From: Andreas Schwab To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: (Stefan Monnier via's message of "Thu, 25 Jan 2024 21:43:01 -0500") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> X-Yow: .. I have a VISION! It's a RANCID double-FISHWICH on an ENRICHED BUN!! Date: Fri, 26 Jan 2024 11:18:20 +0100 Message-ID: <87a5os5rf7.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:a60:0:28:0:1:25:1; envelope-from=whitebox@nefkom.net; helo=mail-out.m-online.net X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Jan 25 2024, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >>> Hmm... I can't reproduce it here (even with native-comp and >>> `--with-wide-int`). >> This build is without native-comp, but it's a 32-bit build. Did you >> try that? I think that's the key to un [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , jm@pub.pink, 68690@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On Jan 25 2024, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >>> Hmm... I can't reproduce it here (even with native-comp and >>> `--with-wide-int`). >> This build is without native-comp, but it's a 32-bit build. Did you >> try that? I think that's the key to unlock this (see below). > > I tried 32bit with and without native-comp, and with and without wide-int, > but can't reproduce it here. Maybe it only manifest itself under w32? https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/13.1/ppc https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/a/armv6l https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/a/armv7l They are all 32-bit with wide-int (with and without native-comp). And the crash happens since 33b8d5b6c5a. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 08:49:10 2024 Received: (at submit) by debbugs.gnu.org; 26 Jan 2024 13:49:10 +0000 Received: from localhost ([127.0.0.1]:50678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTMZy-0003o4-Bb for submit@debbugs.gnu.org; Fri, 26 Jan 2024 08:49:10 -0500 Received: from lists.gnu.org ([2001:470:142::17]:43884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTMZw-0003nS-Bb for submit@debbugs.gnu.org; Fri, 26 Jan 2024 08:49:08 -0500 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 1rTMZj-0008GH-KR for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 08:48:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTMZh-00049U-To; Fri, 26 Jan 2024 08:48:55 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6726A442222; Fri, 26 Jan 2024 08:48:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706276928; bh=QAdoufoVUsQMEZlr1SXgUM2rw7xDwoWGaSNHjFSIz3I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JeUlGm056/1kJDDSmZW8luoqSg839DeCaD30oARhQlcbn7I+84FpC+RRAa+CvCyxj ybsV2cjmMxWyRJn+3l8mA+GWqLhz5WXjDb9AuFdWqa+VcclX/Sgf0JEdfuFP7jmKVx I3dRMqIa6rKTzVcoojrT0ubSjK8wiFuWta+ED2Bw3u0twS/vX5kndC41qp7lprZ/GY ltaVM+Se9gQVCDa8Qc7b8UGeHSXncQ/n4JrL7ErBVa6bQNku6oK+p1e6f3JpkZWcTh T/RZTDmLF/AHeyKpMU1ae3NhXWP4Q4HmHEyYUykzuUA+vJN0A9o0BKo/4tNkstzWEo qjWt2T3+MuCtQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DCE0944222D; Fri, 26 Jan 2024 08:48:48 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A776E12022D; Fri, 26 Jan 2024 08:48:48 -0500 (EST) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: ("Gerd =?windows-1252?Q?M=F6ll?= =?windows-1252?Q?mann=22's?= message of "Fri, 26 Jan 2024 10:26:00 +0100") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> Date: Fri, 26 Jan 2024 08:48:46 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.013 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , jm@pub.pink, 68690@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain > I remembered seeing something in pdumper.c that could be related, namely > > /* Start the cold section. This section contains bytes that should > never change and so can be direct-mapped from the dump without > special processing. */ > dump_drain_cold_data (ctx); > > And if you follow that function you'll see that it treats charsets > specially. > > I find the comment about directly mapping very suspicious, when the > charset contains a Lisp_Object, possibly requiring relocation. But it > could well be that I misundertand something here. Hmm... would a patch like the one below fix the problem, then? Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=cold-charset.patch diff --git a/src/pdumper.c b/src/pdumper.c index f42d1777371..56177d3fd89 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -440,7 +440,6 @@ dump_fingerprint (FILE *output, char const *label, { COLD_OP_OBJECT, COLD_OP_STRING, - COLD_OP_CHARSET, COLD_OP_BUFFER, COLD_OP_BIGNUM, COLD_OP_NATIVE_SUBR, @@ -3245,10 +3244,6 @@ dump_charset (struct dump_context *ctx, int cs_i) memcpy (out.fast_map, &cs->fast_map, sizeof (cs->fast_map)); DUMP_FIELD_COPY (&out, cs, code_offset); dump_off offset = dump_object_finish (ctx, &out, sizeof (out)); - if (cs_i < charset_table_used && cs->code_space_mask) - dump_remember_cold_op (ctx, COLD_OP_CHARSET, - Fcons (dump_off_to_lisp (cs_i), - dump_off_to_lisp (offset))); return offset; } @@ -3402,20 +3397,6 @@ dump_cold_string (struct dump_context *ctx, Lisp_Object string) dump_write (ctx, XSTRING (string)->u.s.data, total_size); } -static void -dump_cold_charset (struct dump_context *ctx, Lisp_Object data) -{ - /* Dump charset lookup tables. */ - int cs_i = XFIXNUM (XCAR (data)); - dump_off cs_dump_offset = dump_off_from_lisp (XCDR (data)); - dump_remember_fixup_ptr_raw - (ctx, - cs_dump_offset + dump_offsetof (struct charset, code_space_mask), - ctx->offset); - struct charset *cs = charset_table + cs_i; - dump_write (ctx, cs->code_space_mask, 256); -} - static void dump_cold_buffer (struct dump_context *ctx, Lisp_Object data) { @@ -3509,9 +3490,6 @@ dump_drain_cold_data (struct dump_context *ctx) case COLD_OP_STRING: dump_cold_string (ctx, data); break; - case COLD_OP_CHARSET: - dump_cold_charset (ctx, data); - break; case COLD_OP_BUFFER: dump_cold_buffer (ctx, data); break; --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 08:49:47 2024 Received: (at submit) by debbugs.gnu.org; 26 Jan 2024 13:49:47 +0000 Received: from localhost ([127.0.0.1]:50686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTMaZ-0003p7-81 for submit@debbugs.gnu.org; Fri, 26 Jan 2024 08:49:47 -0500 Received: from lists.gnu.org ([2001:470:142::17]:50310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTMaX-0003oj-S5 for submit@debbugs.gnu.org; Fri, 26 Jan 2024 08:49:46 -0500 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 1rTMaK-0008JA-H9 for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 08:49:32 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTMaI-0004DQ-Vs; Fri, 26 Jan 2024 08:49:32 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ABA6A10001D; Fri, 26 Jan 2024 08:49:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706276968; bh=u0vubh7561SxDd228FRzbIdzwRT2SXzQ/8KHV8OgBWQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RLDrdLo1MB5RRuM/W4pNoEyHKtRZyLCpV3o6bQ4H8D6QJjGJMfK/MIGe4m7yxc9+b +Slp43KmhHv5u5RL2FoNQblLBzWwuio7/xHJDkGCi8SqDoTCX1nspbzCX6F6y7A07m H3TOKNjuwZTML+ZwaEmyTlm+D6LcAZ2yBZ+VLiWQkOWORzTqGvOOV5iebsRPYKveK/ F1JnRbrtjM6edbq5T3RH2es5kA9lstkQ5hLR3fHdPZMdK0ZLCYcespulc4vfVU8CBh XUE3zHgQQQ4+A2fTlVNqKbykmZIj42nVm8Umf3GEEJV6+LJbUz95yHPol44cYE3pDE 0nfGXaqr94Jiw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 67C6510007D; Fri, 26 Jan 2024 08:49:28 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3443712027F; Fri, 26 Jan 2024 08:49:28 -0500 (EST) From: Stefan Monnier To: Andreas Schwab Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <87a5os5rf7.fsf@igel.home> (Andreas Schwab's message of "Fri, 26 Jan 2024 11:18:20 +0100") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <87a5os5rf7.fsf@igel.home> Date: Fri, 26 Jan 2024 08:49:26 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.033 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , jm@pub.pink, 68690@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>> Hmm... I can't reproduce it here (even with native-comp and >>>> `--with-wide-int`). >>> This build is without native-comp, but it's a 32-bit build. Did you >>> try that? I think that's the key to unlock this (see below). >> >> I tried 32bit with and without native-comp, and with and without wide-int, >> but can't reproduce it here. Maybe it only manifest itself under w32? > > https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/13.1/ppc > https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/a/armv6l > https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/a/armv7l > > They are all 32-bit with wide-int (with and without native-comp). And > the crash happens since 33b8d5b6c5a. Thanks Andreas. So clearly it's not just w32. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 09:31:10 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 14:31:10 +0000 Received: from localhost ([127.0.0.1]:50740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNEc-0004nU-6p for submit@debbugs.gnu.org; Fri, 26 Jan 2024 09:31:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNEZ-0004nD-8h for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 09:31:08 -0500 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 1rTNEN-0007TE-5T; Fri, 26 Jan 2024 09:30:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wpdVovKyrLDttZvsyTsTcOBIfdJ5H0hRr4lAkzJuD8o=; b=YoAcVpxZBwh9gyxxUE2Y uDn4b6igGHkj6mhG19wbiKRa6luUhRMmpenPVUh0QaRp6xJ7dRGYjsgiGDEZFAichhVDwDlCSYe9p qA6y/0Oyq9x6ABPknSmvCUNae+UOOs71Vj4P8Gm8imqCXMYiZjalshJtDGHlvQ4UPLRXQO8jjVKdd Vv362k3HOlzbV2ZhRQOuiuZjqE+nJO6RSfnuOFtdeXQdatHbjyLask3dSP7keuHfBL2kaxhwFCn/L gKw+K5ZdQr/nZM6f8FnyqRxH+mdY9gFCIeQ2xFvcOARq/VvOVGEmg3uPvWGEJQ3QDNKjU3f5ufRGK fIu2Hjm52C30dQ==; Date: Fri, 26 Jan 2024 16:30:51 +0200 Message-Id: <86sf2k9nfo.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Fri, 26 Jan 2024 10:26:00 +0100) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: 68690@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Mllmann > Cc: Eli Zaretskii , Stefan Monnier > , jm@pub.pink, 68690@debbugs.gnu.org > Date: Fri, 26 Jan 2024 10:26:00 +0100 > > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > > > I'm just as lost as you are in pdumper.c, sadly. > > I remembered seeing something in pdumper.c that could be related, namely > > /* Start the cold section. This section contains bytes that should > never change and so can be direct-mapped from the dump without > special processing. */ > dump_drain_cold_data (ctx); > > And if you follow that function you'll see that it treats charsets > specially. AFAIU, that special handling is for dumping fields that are pointers. For example, the string data in a Lisp string, buffer text in a buffer, and the data pointed to by code_space_mask in a charset. But the charset's attributes are not a pointer, they are a Lisp vector. Moreover, the offending charset (ID = 0) is not processed by dump_cold_charset because its code_space_mask is NULL (which makes sense since the dimension of the ASCII charset is 1). > I find the comment about directly mapping very suspicious, when the > charset contains a Lisp_Object, possibly requiring relocation. But it > could well be that I misundertand something here. First, before Stefan's changes there was no Lisp objects in 'struct charset'. And second, what do you mean by "possibly requiring relocation"? Do you mean relocation after restoring from dump, or do you mean relocation during dumping? Or something else entirely? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 09:37:15 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 14:37:15 +0000 Received: from localhost ([127.0.0.1]:50754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNKV-0004vG-Be for submit@debbugs.gnu.org; Fri, 26 Jan 2024 09:37:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNKT-0004v3-DD for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 09:37:14 -0500 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 1rTNKG-0000MO-So; Fri, 26 Jan 2024 09:37:00 -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=79qfXQsUHg6HlrePSYptGu5Dndmf64XE2HqT7lqxMoY=; b=BZkv3LVgi+mn kRSisDFwZ90Z9kRoIF87q6F3RIL7LDZJEA4P8XZoueSTaSZpF6sf/fJ/XzUPvPHS33xiSSEXXsd0L zqTFxTfC3+qJdSADEzRAxX6HBPoue9HOZS8ONcI3Hem45oS3uGWbVCkHk6+gO096w/aihxjefp6jw QRZ1r07bSzyfK2nn3Ud50iXw5ISiqd+Vcmt3FNDU0uXPJtALTSpd/AOGMComfNuAm0L87iKIAUEj3 3za4iDBxAHfLBrcd3fHeEzfzNoDxLK42PWfzzqAUswpgvJflyG4jqrjNL0Slgjy1e794Fx92adOY9 PGCjLfV0Owdqo73cB2D1jA==; Date: Fri, 26 Jan 2024 16:36:52 +0200 Message-Id: <86plxo9n5n.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 26 Jan 2024 08:48:46 -0500) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: gerd.moellmann@gmail.com, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" , Eli Zaretskii , > jm@pub.pink, 68690@debbugs.gnu.org > Date: Fri, 26 Jan 2024 08:48:46 -0500 > > > I remembered seeing something in pdumper.c that could be related, namely > > > > /* Start the cold section. This section contains bytes that should > > never change and so can be direct-mapped from the dump without > > special processing. */ > > dump_drain_cold_data (ctx); > > > > And if you follow that function you'll see that it treats charsets > > specially. > > > > I find the comment about directly mapping very suspicious, when the > > charset contains a Lisp_Object, possibly requiring relocation. But it > > could well be that I misundertand something here. > > Hmm... would a patch like the one below fix the problem, then? What is the logic behind this patch? Anyway, the offending charset (ASCII) doesn't have a non-NULL code_space_mask, so it is not processed by dump_cold_charset. I therefore doubt that this will have any effect on the problem. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 09:47:22 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 14:47:22 +0000 Received: from localhost ([127.0.0.1]:50771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNUH-0005B6-KZ for submit@debbugs.gnu.org; Fri, 26 Jan 2024 09:47:22 -0500 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:49534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNUF-0005At-TD for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 09:47:21 -0500 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-55d4013f3e0so258112a12.3 for <68690@debbugs.gnu.org>; Fri, 26 Jan 2024 06:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706280427; x=1706885227; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wmTM7dKHxaGLAVidHQxUfrZJCliUU3l3opeicpHfuZs=; b=WSD8hGyWxTVRKpxYYu1Ok5B/lb9ZUqWPbrbPKLf27LagOlY+xYYBeBnwXmF7/IxAYP 934KnrGKa3xiUHtnd7b5SlWWBryCo8l8F4Oh3WZaM5xR7YyoblTo1byuKhLCtauVEbNe jvbbe/GRSH82jkUh6ZzmIt/bzFDK/H3efrXmsufcCFKCmp3qMNO+W9hdTlzXX4JFPA1M yjFx5Wpj0V9eKuWQrw+9U/Hr13qmmd68OZHRUMVvJkeiXRcpNDyBJs0OjCD9v6VuURwi EPR+1NHtJkofsw6KHiqiQPNRBX8MZqb20EiLfxMxCarQIFglWDDv4h2Z2FaLbSo18oOI Z56Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706280427; x=1706885227; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wmTM7dKHxaGLAVidHQxUfrZJCliUU3l3opeicpHfuZs=; b=v8DVzrMfOxLwEXGw0V09BEO19raI2LVXQN4T8bp1vkDYm8H3WUhO1plSQeklF5Zqn+ TScBMy38lHL9hi7rfWVLDb8QWudJnMGXD1PpRe5RI7nHn9Ktqom2eyAcqHFMc/debnV5 2XYg35NL3+/I0y9eUj6lOFCTsnhW1KWhpUxX+ie/H6XXzgPEnBbSW+VZ8YwiZqDrMmjQ iZCXg/2jK3Hr2HuyXfAWi9lA3zlPC76+AVmKtM6h0yaqPZtDBCFwNrHE5ZJMEeWdWulW 2a/F0IzjYlVDaaCY0ylHF1XJxXbADNo05cqCE+Mf38ZzTVL+BZwwMAB9tNzmZ+/z0wxe OGMg== X-Gm-Message-State: AOJu0Yyt3FS4yhpTEs5MMSjwwyXGLYDdFmwZDpWWjE/rNaSVbWcWLj41 tdxOBZuqdnNIu2ztZo0shZRoAwC7l5+fzn2WaqkXJDILim9ZGbuV X-Google-Smtp-Source: AGHT+IFcNRolARMmOCNEln3uOKcG1ZjjBMsL5F8+pzaR2/30TQm7MXa8qHMyhqZQTyqa5+mNqnIB0g== X-Received: by 2002:aa7:cf12:0:b0:547:9f26:e581 with SMTP id a18-20020aa7cf12000000b005479f26e581mr944927edy.37.1706280427301; Fri, 26 Jan 2024 06:47:07 -0800 (PST) Received: from Pro.fritz.box (pd9e36b3f.dip0.t-ipconnect.de. [217.227.107.63]) by smtp.gmail.com with ESMTPSA id i9-20020aa7c709000000b0055c340e2ad8sm653388edq.19.2024.01.26.06.47.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 06:47:06 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86sf2k9nfo.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Jan 2024 16:30:51 +0200") References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> Date: Fri, 26 Jan 2024 15:47:06 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68690 Cc: 68690@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , Stefan Monnier >> , jm@pub.pink, 68690@debbugs.gnu.org >> Date: Fri, 26 Jan 2024 10:26:00 +0100 >>=20 >> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of >> text editors" writes: >>=20 >> > I'm just as lost as you are in pdumper.c, sadly. >>=20 >> I remembered seeing something in pdumper.c that could be related, namely >>=20 >> /* Start the cold section. This section contains bytes that should >> never change and so can be direct-mapped from the dump without >> special processing. */ >> dump_drain_cold_data (ctx); >>=20 >> And if you follow that function you'll see that it treats charsets >> specially. > > AFAIU, that special handling is for dumping fields that are pointers. > For example, the string data in a Lisp string, buffer text in a > buffer, and the data pointed to by code_space_mask in a charset. > > But the charset's attributes are not a pointer, they are a Lisp > vector. > We're probably talking about different things. I was talking about the fact that struct charset, before Stefan's change, sonsisted of, basically, integers only (no pointer, nothing), so that it could just be dumped as-is, and, after loading the dump file, used as-is. > Moreover, the offending charset (ID =3D 0) is not processed by > dump_cold_charset because its code_space_mask is NULL (which makes > sense since the dimension of the ASCII charset is 1). > >> I find the comment about directly mapping very suspicious, when the >> charset contains a Lisp_Object, possibly requiring relocation. But it >> could well be that I misundertand something here. > > First, before Stefan's changes there was no Lisp objects in 'struct > charset'. My point. > And second, what do you mean by "possibly requiring relocation"? Do > you mean relocation after restoring from dump, or do you mean > relocation during dumping? Or something else entirely? Lisp_Object fields require writing something to the dump file that can be used, when the dump is loaded, to compute the real value in the the new Emacs session. So, something is done when dumping, and when loading. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 09:50:56 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 14:50:56 +0000 Received: from localhost ([127.0.0.1]:50776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNXk-0005Mh-EC for submit@debbugs.gnu.org; Fri, 26 Jan 2024 09:50:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNXi-0005MP-Hl for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 09:50:54 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A1FCB10007D; Fri, 26 Jan 2024 09:50:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706280641; bh=PVp1kNZzMo2BsLtjKRvmYU/e4snn4G86cmQTaNpp0FA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Hpvq/gtgZ6W68nOUuw1yYM5NwgQposqhlhJ4c5Bme2V+G7Cgtiwugo5LeGuZjqHvG JsH9tB5PnTV40xDbAgeqqsrs7OmUjY7bcF9bQUMFi0g2W9Cjpn1ZVTh/z40MTEmQa+ UdOWicZv0fEWqajxEIhXplFb0hjwd5U6CK7OnaNFg1neWXu/IDzCwU/gDeMJKrbKxL pMejJ5jtQDb4TkNO6s/9ylsZ3ClV35c6lsRXiApD15IwPooQ243UooRS2ZPvmhXcdz yZ3aJa05yRYyLD/mSDRqybH8P2e+8jXk9noxgDg+k8AGTnk2KfKIKV742NEcioVLRA 9YtM/UwFMqWhQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7141710001D; Fri, 26 Jan 2024 09:50:41 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 515E212097B; Fri, 26 Jan 2024 09:50:41 -0500 (EST) From: Stefan Monnier To: Andreas Schwab Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: (Stefan Monnier's message of "Fri, 26 Jan 2024 08:49:26 -0500") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <87a5os5rf7.fsf@igel.home> Date: Fri, 26 Jan 2024 09:50:36 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.228 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , jm@pub.pink, 68690@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Thanks Andreas. So clearly it's not just w32. Ha! I can reproduce it on my `armhf` machine! Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 09:56:03 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 14:56:03 +0000 Received: from localhost ([127.0.0.1]:52312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNcg-0005uM-KD for submit@debbugs.gnu.org; Fri, 26 Jan 2024 09:56:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTNcf-0005sM-Dy for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 09:56:02 -0500 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 1rTNcS-00061y-VQ; Fri, 26 Jan 2024 09:55:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=omd3gCj2IWwa3UeNc+VzZx/3TuTopQtNlGQ6L7PKeD4=; b=RB8bDaDWteZ+4qyUqng0 tpI0gUC0vvKRZq8SCUIXYEKMhZU2+UIdzcOu1vHbxCq6u24E4X/841NcJnV6YskfJ4pb7ysmipohL /AvMog8e7MZSINIrFgQjNQslXlkQAgve7FWjCR8K/C6hV6hA44jCfHtOmzMLlaG/rEh5boj6ayhDW HxNbMefVjlcABCGH+LRxplVH/4JTNhfaqxgAtE4dx51HNWaE6vpaxm6wEThG8z02DNqxQM+yZ2z6v gPT+HQWRKhN72wTodTkU7yOH89meQPN7OoktgTLMwN5HtaAdeM/4uA+JrDOmNRMRDhKh44ncBb8lz zyKwfOscrLSVaQ==; Date: Fri, 26 Jan 2024 16:55:45 +0200 Message-Id: <86msss9ma6.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 26 Jan 2024 15:47:06 +0100) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: 68690@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 68690@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Fri, 26 Jan 2024 15:47:06 +0100 > > > And second, what do you mean by "possibly requiring relocation"? Do > > you mean relocation after restoring from dump, or do you mean > > relocation during dumping? Or something else entirely? > > Lisp_Object fields require writing something to the dump file that can > be used, when the dump is loaded, to compute the real value in the the > new Emacs session. So, something is done when dumping, and when loading. Something _is_ being done, AFAIU. If you step through dump_field_lv, you will see that it dumps a placeholder (0xDEADF00D) instead of the actual value, and records a "fixup" to be processed later. When the fixup is processed, it schedules a "relocation", which AFAIU is supposed to replace the placeholder with the offset of the actual Lisp object in the dump file. So the machinery seems to be in place, it just doesn't work somehow in this case... From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 10:52:08 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 15:52:08 +0000 Received: from localhost ([127.0.0.1]:52490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTOUy-0001qK-1j for submit@debbugs.gnu.org; Fri, 26 Jan 2024 10:52:08 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTOUw-0001pq-IH for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 10:52:06 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 91DEB10007D; Fri, 26 Jan 2024 10:51:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706284312; bh=IzYdqD/4KVp6aq63YYhgmE/ZwCv6BfKHiCn7jeto0sQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XwaqRIybTd2j97YlGLSB5uewZDwH5snt4kLq9uA8zAw04tdRdlq2NJa8fv6bK2bTr mbn4m9en2OeNZczQYSe5xxBF1scCqxGgfj60Hy1MQUfptPHnwXqeiYiYAGP9J0Twu+ HnBxCBGmTqZBl/LJeBZkfz/WWOZBVrFblLtK0WOO2jTtLLs+o+EDJEaqYHdb0GmWFg R11HCtaOGuSYR9nH11KPWKhem64DFC/TZsZBgMhWDkIEZJV2bcGVz5wzShX+bfJacH OogXDQPuqw7nMedd6Za0XgQe53t1+se0Oq/BRlh/iILcBRlyEAex/dVhBsaaxdJ9Bz q410NdKGEw/AA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7B14010001D; Fri, 26 Jan 2024 10:51:52 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5E6C9120403; Fri, 26 Jan 2024 10:51:52 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86plxo9n5n.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Jan 2024 16:36:52 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86plxo9n5n.fsf@gnu.org> Date: Fri, 26 Jan 2024 10:51:51 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.190 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: gerd.moellmann@gmail.com, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Hmm... would a patch like the one below fix the problem, then? [ Tried it on armhf. ] > What is the logic behind this patch? The logic was "shot in the dark". As usual, that logic didn't give good results. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 11:07:33 2024 Received: (at 68690) by debbugs.gnu.org; 26 Jan 2024 16:07:33 +0000 Received: from localhost ([127.0.0.1]:52498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTOjt-0002Dk-Ak for submit@debbugs.gnu.org; Fri, 26 Jan 2024 11:07:33 -0500 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:48224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTOjq-0002DU-Bu for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 11:07:31 -0500 Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-5100ed2b33dso1303028e87.0 for <68690@debbugs.gnu.org>; Fri, 26 Jan 2024 08:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706285238; x=1706890038; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=oK+Tp20/aStRnxNuHSLwK+CinIJQxjKdEXDCRBmdMNw=; b=efuakYurVDuoLcpUwKPbi6rcq8+E+Zgz2cJwjNeawQWKn0jsDga1Wnxqy5iPhx9lr6 wZux2mlnn/cWrYtuz1C/ylDBio1iUo/xyUU8aw8J2ovRjsxpv3b+I0CrNmmBFcLJb/h9 Y/Bs0C/N1oW8OckTzgNHvnD607NBnie8Y6KpvsGL0qbG0eVeB0nraq3VFewGlkiuL/ea BUmXToIHxwM2i4sPQQsVUqtErooJ+c7mIkkVmCBeKjxmSCmTZKIeOYmVKl8zgbW6UEYq dIrV3cT5OsJJgFM3Rbbjkp9wFG+PWY6kW9qcZAhOIcBHWxiFHi59Xt4WfFFQXkH62OIf my5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706285238; x=1706890038; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oK+Tp20/aStRnxNuHSLwK+CinIJQxjKdEXDCRBmdMNw=; b=QMc0LSk6kBpzWL66vX3gGNHS+1B6QNwFMtA5yIvphemg7lNb1VeXlncpQkGYrJHs9k UnOFf8ciY7jUIrvrOMrqrVoqHsdmy6W/8RBwwcQFOoVEgL4YXYlzXCOk0v9sHnQUD+g5 evhfSbc9/1e25+71wsmR4zTPTb6qeWAR9HkLzx72V53ROWCQxqmvo1dyLqVbzRf3U6Vi woUKg3ASDojVvn7cDwV6qGMJ/z+3GkWRLxKAYl7XGoVQ22JjISI79BD5UD151vbsq7GO +NusbhitBdQgmJ6Fd13lZVcdiGk1BhW7WqTsCTVCm7SD8U7jCOR2crc/biDEIRmy74RK tyxQ== X-Gm-Message-State: AOJu0YxVpheoVu2IjE7NfxZUkq/8kKnkFicetZ7jC9EmMv0pVvplO/fT blYrVruMlHzJI5pdj938x35UJfKlKtZw9kYKFAEuUCpGD/7QRUey X-Google-Smtp-Source: AGHT+IGqG7PKlOeLa7Gmhn/sK+xU4qsbaShzZxJntbDQF43Hi+mP0LYFZpTHjFNQS1b0sCHGWAWn1A== X-Received: by 2002:ac2:47f7:0:b0:50e:db6c:f014 with SMTP id b23-20020ac247f7000000b0050edb6cf014mr768441lfp.48.1706285237445; Fri, 26 Jan 2024 08:07:17 -0800 (PST) Received: from smtpclient.apple (c80-217-1-132.bredband.tele2.se. [80.217.1.132]) by smtp.gmail.com with ESMTPSA id c9-20020ac25f69000000b005101772e298sm214935lfc.19.2024.01.26.08.07.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2024 08:07:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#68690: Segmentation fault building with native-comp From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Fri, 26 Jan 2024 17:07:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <290E2D8C-E0FA-479C-A79C-6651587B965D@gmail.com> References: To: Stefan Monnier X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68690 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , jm@pub.pink, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 25 jan. 2024 kl. 23.39 skrev Stefan Monnier : > AFAIK the current DOHASH code in `master` works fine (tho a bit ugly). I think it's less good (and more complex) than not trying to cache = anything at all where the compiler actually will help out a bit, and = it's slower than the fast caching version. > The build failure didn't come via maphash` but via the DOHASH in > `comp.c` that calls `compile_function` (which apparently can cause the > hash table to be resized). Do you know which one? It's quite possible that that code wasn't written = taking into account the problems of extending the table being iterated = over. We should definitely ask Andrea. Meanwhile, I suggest adding a DOHASH_SAFE (simple, safe) to be used in = these cases, including Fmaphash, and use the (someone less simple, fast) = DOHASH in my previous patch with an extra assertion to catch mistakes = elsewhere in checking builds. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 19:09:11 2024 Received: (at 68690) by debbugs.gnu.org; 27 Jan 2024 00:09:11 +0000 Received: from localhost ([127.0.0.1]:53067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTWFz-0007Rc-CW for submit@debbugs.gnu.org; Fri, 26 Jan 2024 19:09:11 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTWFx-0007RP-Sc for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 19:09:10 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 72D8144471C; Fri, 26 Jan 2024 19:08:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706314136; bh=E8LEValce/G3dyJwJ3Mcy2eluNLGYw+EAE0ZevYHczQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SKJl7KDmue3IM3MRG6LqWR97hBkT7scg9QaiQuSZnfKsdWZOXZ+lrTMMkFrHkNilr B9d/W4yMpt+NDiOQsOqtKkhjte3CkBSjJgL3h/7YVhohn2X9tyC8HObBlDiFjNSnzk /NCFht478dXPJXw9GkieT1V3GIUIRa2z3dOh+V6GLnmoJSoR836dXMK7bNTELjZwZO UaTNtvGOkcs5AaG2YYth3fddhvvUQYDW9hhH6GKk/iC5iYio2ApS5w16ruRsStNquv R54XmzVF8s0UhIZgF6aPoi2HdxnSH2MkDf63xTcekKApY5fVhJBA13XHzKd/9TE2U5 A4XGxyXzOYa/w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 49C58444716; Fri, 26 Jan 2024 19:08:56 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20C85120209; Fri, 26 Jan 2024 19:08:56 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <86msss9ma6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Jan 2024 16:55:45 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> <86msss9ma6.fsf@gnu.org> Date: Fri, 26 Jan 2024 19:08:55 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.008 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I've been spending a lot of time on this and still haven't found the origin of the problem nor a fix. Here's what I have currently, in short: % src/bootstrap-emacs --batch -f batch-byte-compile lisp/ido.el charset 0: a0000000f20e1328 => f1f2c070 CHARSET_ATTRIBUTES(ID=0, cs=f1f2c064) = f20e132800000000 (@ f1f2c06c) lisp.h:1784: Emacs fatal error: assertion failed: VECTORLIKEP (a) The first message comes from `dump_do_dump_relocation` when we load the dump file and shows (I believe) the relocation we do for the `attributes` field of the charset 0: we write the (relocated) Lisp_Object value `a0000000f20e1328` at address `f1f2c070`. The second message comes from `CHARSET_ATTRIBUTES` which tells us that it reads the Lisp_Object value `f20e132800000000` at address `f1f2c06c`. I sadly have no clue yet why there is this 4byte difference between those two addresses (but it does explain the bogus Lisp_Object we get). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 23:07:49 2024 Received: (at 68690) by debbugs.gnu.org; 27 Jan 2024 04:07:49 +0000 Received: from localhost ([127.0.0.1]:53239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTZyu-0005d5-SE for submit@debbugs.gnu.org; Fri, 26 Jan 2024 23:07:49 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40357) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTZyt-0005cq-EU for 68690@debbugs.gnu.org; Fri, 26 Jan 2024 23:07:47 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 73ACF10007D; Fri, 26 Jan 2024 23:07:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706328453; bh=kjUkTIdRwWj548bzCnkU0ebwMqhFrxsqFAdpXchoV2g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JycxO7QDvpvP4ew9LQB/Uwlp12EGsUg0ZNcT5eQ1VeJWXtBlCvchmbE1sTlMgl96F ANrYrDEzC06AF3xwWPUdBZWL9MPdX0tXk6dJrGQx4HqfH4/Rh/U2K9NCmB6xgWPnzp sakG/6JXPi7hDWYlz/AWPjS2h2jte1g1ip62wxN88khJ2M4dEjVLlPLyHA63KZqPKM pn14JuHpo+HMqyqbh7DHL6IYt7Q/neTKEOdhVdOh0moJ5KZtuPHZJY/2R1iSeIzd8w mzIbpPg71bY3BMlGHIJYms2tbJ//BHW3/lFxMJ4UR9hUIeKKxcdz2PTxLzKe3aTmis LKmg3YUOzknLA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3423810001D; Fri, 26 Jan 2024 23:07:33 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BEF6B1208CC; Fri, 26 Jan 2024 23:07:32 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: (Stefan Monnier's message of "Fri, 26 Jan 2024 19:08:55 -0500") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> <86msss9ma6.fsf@gnu.org> Date: Fri, 26 Jan 2024 23:07:31 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.032 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I sadly have no clue yet why there is this 4byte difference between > those two addresses (but it does explain the bogus Lisp_Object we get). OK, I think I found it. Please try again and let me know if it fixes it for you. Damn, that was a nasty bugger! Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 27 02:51:15 2024 Received: (at 68690) by debbugs.gnu.org; 27 Jan 2024 07:51:15 +0000 Received: from localhost ([127.0.0.1]:53379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTdT8-00042O-Th for submit@debbugs.gnu.org; Sat, 27 Jan 2024 02:51:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTdT6-000422-Nk for 68690@debbugs.gnu.org; Sat, 27 Jan 2024 02:51:13 -0500 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 1rTdSt-00048y-Ne; Sat, 27 Jan 2024 02:50:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=oV8d7E1iV2MU2OUx+Hf8eyjwDtAcNJmDQR2dOYt9Atg=; b=i4BSZZRc6n0oZ0KUNOYf aXXMpsJqnCCHD+47P2N0xeQo8UzMMX5tTMezchhrSh8IENYkJcIWG1E19RczFv7FErKETEIW60mCc /fGkMnf1W9NPMMFOtFAy7l+x3rsO7356BKeSLsl0COVljj6ohla0OzCjQ/8jwDgQI7gEvjca6eu9w PRVFL1xxVTXwH1DcW/re3XmtWuAMyogfUJPCa2Spiq8hTvmTGPvhcyvLR3/lBSKaaDPv6jxvtMkmP 1/iy1gDZ2MDd3wTRgh3hV6J4Ey962aYCZ/BIp1UQeRYPguIe0EZ/MY05X3qlAbulQ7c0zmhd5Ehcq YrU91KGHwmShLw==; Date: Sat, 27 Jan 2024 09:50:56 +0200 Message-Id: <865xzf9pun.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 26 Jan 2024 23:07:31 -0500) Subject: Re: bug#68690: Segmentation fault building with native-comp References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> <86msss9ma6.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690 Cc: gerd.moellmann@gmail.com, 68690@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Gerd Mllmann , > 68690@debbugs.gnu.org > Date: Fri, 26 Jan 2024 23:07:31 -0500 > > > I sadly have no clue yet why there is this 4byte difference between > > those two addresses (but it does explain the bogus Lisp_Object we get). > > OK, I think I found it. > Please try again and let me know if it fixes it for you. > Damn, that was a nasty bugger! Thanks, the build works now. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 27 09:45:52 2024 Received: (at 68690-done) by debbugs.gnu.org; 27 Jan 2024 14:45:52 +0000 Received: from localhost ([127.0.0.1]:53714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTjwN-000221-PL for submit@debbugs.gnu.org; Sat, 27 Jan 2024 09:45:52 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTjwJ-00021d-P6 for 68690-done@debbugs.gnu.org; Sat, 27 Jan 2024 09:45:50 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C2D844414D5; Sat, 27 Jan 2024 09:45:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706366733; bh=ACOwVnh3Rj2fav44TTJIsgH1B+0VH8M7XZgcO0u/NA0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QK+UZFqPqdLNVf8bsmquCMIoEF4WUpWNYtQPahqpUr8xwmedpG1hAjFDNSsnrYmUS IKJsXv8ZiB8DwzKqoXlDCqQTy/7Gf7zobZo3ZalLHjz0GqqgD2UP4u6lQJVf4KqRu3 I03taRAKKnzRpxAAeSG/QrTKr73V3GvIXcbFuwuQzjPRbpferwvQgtaZ6NQJ8xKyVz cuNkiSP4UIocpKJlTrlL5w3hvJAtoKQHJw+J4CtR5AHsrVyk+ZuduhdBetn6pmZnU1 THFvsqc9GmrHYlkf6b7ADLoTXUdF+jr7muXsSKH7i9BFPdYG589U07CSwTpZpv+ajN 2E8YZPHAh6sMA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 901E44409A6; Sat, 27 Jan 2024 09:45:33 -0500 (EST) Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 662AF1200CC; Sat, 27 Jan 2024 09:45:33 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68690: Segmentation fault building with native-comp In-Reply-To: <865xzf9pun.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Jan 2024 09:50:56 +0200") Message-ID: References: <87wmryel78.fsf@pub.pink> <86zfwud5cv.fsf@gnu.org> <86sf2mcwa2.fsf@gnu.org> <86le8dd7ze.fsf@gnu.org> <86sf2k9nfo.fsf@gnu.org> <86msss9ma6.fsf@gnu.org> <865xzf9pun.fsf@gnu.org> Date: Sat, 27 Jan 2024 09:45:32 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.004 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68690-done Cc: gerd.moellmann@gmail.com, 68690-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> > I sadly have no clue yet why there is this 4byte difference between >> > those two addresses (but it does explain the bogus Lisp_Object we get). >> OK, I think I found it. >> Please try again and let me know if it fixes it for you. >> Damn, that was a nasty bugger! > Thanks, the build works now. Great, closing. Stefan From unknown Sat Aug 09 04:52:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 25 Feb 2024 12:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator