From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 09:53:11 +0200 Message-ID: <86ikqn14wo.fsf@gnu.org> References: <87zfk0p741.fsf@no.lan> <861pxc2l6y.fsf@gnu.org> <87wmf42gdx.fsf@protonmail.com> <87frlst34b.fsf@no.lan> <87plkv3hzd.fsf@protonmail.com> <86msfz16na.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6876"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, telegraph@gmx.net, 75459@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 10 08:54:23 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tW9qY-0001cK-8v for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Jan 2025 08:54:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tW9qG-0002sp-0R; Fri, 10 Jan 2025 02:54:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tW9qE-0002sO-4Y for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 02:54:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tW9qD-0004Xy-Sn for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 02:54:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=/On83AB2qkf6diuBOLm8E6xpaP1MkGrQilqfEaS204U=; b=CNlP0XmsqQVdw7An86J5SDujz6/T1uGM7JN+LCvBNPu3k2LNfcZ+FKFoXAFBpHnPrGuBzqiE5EJYI6V8xqpsyPiTfPlm9gn3Fv2kVIuKxIJ4lUy4srZTmSa14rs7Lya9hO8mXz0yWwbM5NJkyrECnUqR9YE+2qPFP6xg6AsGHkSdHXXWh1KAECE8KEh4ts/9/9KSersFsw2ASusqS3m/q9mK6Ua0vfiwrkFNN7o2LS7auN5/FadAADbWCfum+fPRggXcdr1F8XIykoBEoPNiuFoJZ1G84XkNa05xJzHlEOHrusRDWsNlrVAIHcPkmYN4uwiCg2nXFNVf0rbDMv9Paw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tW9qD-0002eK-J8 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 02:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Jan 2025 07:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75459 X-GNU-PR-Package: emacs Original-Received: via spool by 75459-submit@debbugs.gnu.org id=B75459.173649560610141 (code B ref 75459); Fri, 10 Jan 2025 07:54:01 +0000 Original-Received: (at 75459) by debbugs.gnu.org; 10 Jan 2025 07:53:26 +0000 Original-Received: from localhost ([127.0.0.1]:56284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tW9pd-0002dU-Fj for submit@debbugs.gnu.org; Fri, 10 Jan 2025 02:53:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53950) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tW9pa-0002dG-P0 for 75459@debbugs.gnu.org; Fri, 10 Jan 2025 02:53:23 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tW9pV-0004WD-2t; Fri, 10 Jan 2025 02:53:17 -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=/On83AB2qkf6diuBOLm8E6xpaP1MkGrQilqfEaS204U=; b=r2nbi95ZHt1KfoyUM4mT QiNsB6cCzG93Oa14US9p6Bet2VLvfXo0iuj/VlCLqO4dCBb4A7mYK3BhWDBL9mo5l0qtaYLfzHCjB qy510TwtYmHRqfEKjVfFb7ZhHJYsrIvuHCcv04nmzvZ55+SJGLCA0zWvCynqjtHu6676piLmRcC2K KZDjfyvjhmUdH1eF4ZtyfdCwO1VUfL8aLGnlI05I2tE/iInVwwi/xrKaK5VXRd7qgqqUO2d83t05n m/BP//X7qKVBH+u9ElWDOendPfyRakqezMwACyS8l3fKnILILwqSUOJDbCOLUoW9XAxrSWU8Sid89 jeIt1lDKImqzJA==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Fri, 10 Jan 2025 08:29:21 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298870 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, telegraph@gmx.net, 75459@debbugs.gnu.org > Date: Fri, 10 Jan 2025 08:29:21 +0100 > > Could the problem then perhaps be barriers? In emacs_lldb.py I have, for > LLDB, a command > > def xpostmortem(debugger, command, ctx, result, internal_dict): > """Call igc_postmortem to set MPS arena to postmortem state""" > debugger.HandleCommand(f"expr igc_postmortem()") > > I call that command manually when MPS gets in the way. Here is the > description from MPS Maybe. We could add that to the xbacktrace command. However,... > In the postmortem state, incremental collection does not take place, > objects do not move in memory, references do not change, the staleness > of location dependencies does not change, and memory occupied by > unreachable objects is not recycled. Additionally, all memory protection > is removed, and memory may be in an inconsistent state. > > Warning > > After calling this function, memory managed by the arena is not in a > consistent state, and so it is no longer safe to continue running the > client program. This function is intended for postmortem debugging only. > This function must be called from the thread that holds the arena lock > (if any thread holds it). This is the case if the program is > single-threaded, or if it is called from an MPS assertion handler. When > calling this function from the debugger, check the stack to see which > thread has the MPS arena lock. ...the above makes me wonder whether calling this unconditionally will shoot us in the foot. Debugging with GDB does sometimes call functions in the debuggee, whereas the above says "no longer safe to continue running the client program". I wonder what kind of "postmortem debugging" they had in mind, perhaps only debugging MPS-related code itself? In any case, we should call this function only once per run, and in the context of thread 1. So maybe calling it manually, like you do now, is the best alternative? In which case we should add this to etc/DEBUG, I think.