From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 13:46:40 +0000 Message-ID: <87ldvi3hok.fsf@protonmail.com> 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> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39499"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 14:47:18 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 1tWFM6-000A9S-0S for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Jan 2025 14:47:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tWFLs-0005wd-Vj; Fri, 10 Jan 2025 08:47:05 -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 1tWFLr-0005wQ-S6 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 08:47:03 -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 1tWFLr-0001Ho-20 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 08:47:03 -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=wok2Ukowuns9UvIsiyf+iFv1s1J6ZqIQM/f/JMlX4V0=; b=IMfUJOU/3Jto5wRQJt4wmr7L7AcVwE3NpcVgnw5WgSzTOmVIhQFSH2Alz8+P8BS23VRz+8SrQqeMfcqXR73Nw1+4D+6ja9sZvfKma0VE3130GFOaT+w4dwHwprN9ZDsrwD7bG1UGiGr9wJEFgu+rpsMqPnTa+t0gtw16lapEj4qPyMSOA9dWjWCFYs9SGR7drEFO6qF1L8/KIMc8PBOqmaQn3CF92oc02LXXpFGKfR2twpJV+s7UjDFKGmi2W0r2aCGldsdCihf2Jsp57PlhcCRckUzdLcwuQ6kXS3vmnB3Hb4T8/JxwwDX5R2SPbmFmnxMxm9LSJOWd/4ikBUIlbA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tWFLq-0002Xo-Ha for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2025 08:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Jan 2025 13:47:02 +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.17365168169765 (code B ref 75459); Fri, 10 Jan 2025 13:47:02 +0000 Original-Received: (at 75459) by debbugs.gnu.org; 10 Jan 2025 13:46:56 +0000 Original-Received: from localhost ([127.0.0.1]:56761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tWFLj-0002XR-RG for submit@debbugs.gnu.org; Fri, 10 Jan 2025 08:46:56 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]:45999) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tWFLh-0002XA-Nk for 75459@debbugs.gnu.org; Fri, 10 Jan 2025 08:46:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736516805; x=1736776005; bh=wok2Ukowuns9UvIsiyf+iFv1s1J6ZqIQM/f/JMlX4V0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=UfHsONBfF4SOSIOydbgamX/yaxDubdfT/2XHzCOq7BG7movLEiKb4tp1Hn1UwoRMq QWPZ4lhhDeMlxmyTW2bwacZOOR8Bi0LhFmtfXq9QI3G3DxDRKb8O9ajHCL5JFJjEom FZk02s/xEGk2NTRYJWaS7hpOLu+B/Nw2K3UPfRl1re2dXrKvoNlQrqKIO6uvy/Xohi j23vy7qUbrQA2tDo/Zi+tk3vIeXPRmHa41JlCALRjRJoF1+ojAnu7ll2ptIsM0hOFK hypVI1k3zplmnilCMvGjCVkdWBoxvgdVAwjb4ZWxiOv/LYcJyRrMi9uAl5YcyMPF+r ZL4bGJpWd3hAw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f99708ea68bb0dff6631e5b9096ec257f5b147a5 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:298881 Archived-At: Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >> The xbacktrace command is automatically called by GDB as a post-hook >> of the "bt" (backtrace) command. So when the functions called by GDB >> to generate the Lisp backtrace crash, you see more calls to >> terminate_due_to_signal, which again hit the above breakpoint. > > Ah, that explains it, thanks! Didn't know about that hook. That explains why "backtrace" doesn't show up; it doesn't explain why backtrace_function asserts on data that we previously ensured would be of the right kind. As the stack pointer is nowhere near the data that was clobbered, I have no idea what's going on here. .gdbinit ensures we're looking at a frame with pdl->kind =3D=3D SPECPDL_BACKTRACE, we call backtrace_function, which is meant to be backtrace_function_body, which easserts the very same thing we just tested, but finds it is no longer true. Maybe backtrace_function is no longer equal to backtrace_function_body, but backtrace_function should be in the .rodata section, which should be protected against modification (but GDB has no problem modifying it, and doesn't even issue a warning when doing so; another GDB bug, IMHO). > Could the problem then perhaps be barriers? In emacs_lldb.py I have, for I don't think so: barriers don't cause SIGABRT (not even when the "barrier" is unknown and MPS gives up; in that case, MPS restores the SIGSEGV handler and raises SIGSEGV again; I think that's an MPS bug, BTW: what MPS should do is to restore the SIGSEGV handler and return from the handler, which will cause the faulting instruction to be re-executed, which will, in turn, call the original SIGSEGV handler with a siginfo structure), and the eassert in backtrace_function accesses the specpdl, which is (unfortunately) an unprotected root. > 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 Does lldb allow you to inspect memory that is behind a barrier? GDB does (which is good), but doesn't warn about it in any way. That is very, very confusing behavior. I think it qualifies as a GDB bug which should be fixed (but the last GDB bug I reported was a +1 on a 20-year-old bug report that was never responded to in any way, so maybe reporting further GDB bugs is a waste of time). I don't think the decision to abort MPS and access the data in whatever (presumably inconsistent) state it was left in is one that should be made automatically, and that applies both to calling Emacs functions and to using GDB commands. If calling backtrace in GDB means we can't continue afterwards, that would be very bad. I think it's already bad that we automatically append the Lisp backtrace to "bt" output. IMHO, "bt" should limit itself to accessing process memory via PTRACE, not call into application code. Making it destroy the Emacs session even when we can get a backtrace would be worse. Pip