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#72165: 31.0.50; Intermittent crashing with recent emacs build Date: Mon, 29 Jul 2024 14:45:52 +0300 Message-ID: <86cymwzaj3.fsf@gnu.org> References: <87o76veo04.fsf@secretsauce.net> <8634o7gusx.fsf@gnu.org> <874j8n6u1x.fsf@secretsauce.net> <86frs7f2n7.fsf@gnu.org> <87a5idj0yg.fsf@secretsauce.net> <87msm0ud0z.fsf@secretsauce.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15409"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72165@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 29 13:47:13 2024 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 1sYOqO-0003qS-K2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Jul 2024 13:47:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYOqA-0007nA-TL; Mon, 29 Jul 2024 07:46:58 -0400 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 1sYOq1-0007m7-U1 for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:46:51 -0400 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 1sYOq1-00016g-Dp for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:46:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=TRfFDDiT/4XawkRvU+ffTWzVnDm37F11HXYIp970Zq4=; b=iomhMv2hUEul1cvj/s6j2d66dwYOb9WvyP/MvMKa1Rk4o/qGA+u9eHkC2HcUhpi5TvcnKUQJ18T0GiTiP82Tw3bWWs41GfQXthMpjO42nWD1LaqrRp5dlFMoVltT7ETBZxdoFfa6qw0QZIGhYmwvXmDhebqqA69VYBSPhsVdWGwcCxi5e3p0cuqqrSyznqZSqxLrjuKciEJkLXtDhmNPHQwIxjf+9gjqDAaH+uzNoemSHBZUzDUmYHbazEKQi1iIj+b+HlkH6Inpar4+M4pgiitPgphtIawcoasdrAAwvsTXj7IKl7rAy1l9YlEvBGZ5bbaLBbqKq3gyE9fzMgmD8w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sYOqE-0001NA-22 for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Jul 2024 11:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72165 X-GNU-PR-Package: emacs Original-Received: via spool by 72165-submit@debbugs.gnu.org id=B72165.17222535835212 (code B ref 72165); Mon, 29 Jul 2024 11:47:02 +0000 Original-Received: (at 72165) by debbugs.gnu.org; 29 Jul 2024 11:46:23 +0000 Original-Received: from localhost ([127.0.0.1]:45050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYOpX-0001Lv-CF for submit@debbugs.gnu.org; Mon, 29 Jul 2024 07:46:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYOpS-0001Lg-Fl for 72165@debbugs.gnu.org; Mon, 29 Jul 2024 07:46:18 -0400 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 1sYOpA-00012c-5Y; Mon, 29 Jul 2024 07:45:56 -0400 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=TRfFDDiT/4XawkRvU+ffTWzVnDm37F11HXYIp970Zq4=; b=WHTFPLPd6nIT zEYYVixiRmNbIZLxDVZvleY3OCsumQqUZFZmJxTQMfYuAS1Se4vCSbHQQNVHKlnW1iaayKIZbJPtq E4eZDIjwqAuMVGJYt4W2Hn6JIOSpeuwP8nygPDbIu3Z2L70GF4Tf0rZW1bQ2diHQJL3vYM1aZdMvh JkWH6dq952uMySvD6+Cy/+mcWj7DXRxN3+cveQJX3LhFRd4fOeiCMGa9j+jX2ViNcmfWQBG7cvtoG aaxllGGWeKhswhHu2wo90jhLx/YisMRYAc7vLTPtvTakFIVuy81QNVPWb7Ow9jFcgxzp9F+fSc9Ts sWDVTay4uQCVtttbdybqIg==; In-Reply-To: <87msm0ud0z.fsf@secretsauce.net> (message from Dima Kogan on Sun, 28 Jul 2024 19:50:52 -0700) 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:289517 Archived-At: > From: Dima Kogan > Cc: 72165@debbugs.gnu.org > Date: Sun, 28 Jul 2024 19:50:52 -0700 > > Alright. After some flailing I was able to make it crash with rr, so now > I can see EVERYTHING. rr is truly a miracle, and figuring this out > without it would have been impossible. Thanks for persevering. > Then on line 12177 we check if we're exceeding message-log-max, and if > so, delete some stuff from the *Messages*. > > if (FIXNATP (Vmessage_log_max)) > { > scan_newline (Z, Z_BYTE, BEG, BEG_BYTE, > -XFIXNAT (Vmessage_log_max) - 1, false); > del_range_both (BEG, BEG_BYTE, PT, PT_BYTE, false); > } > > In the failing sequence we delete some of the non-ascii characters. So > the byte-char offset changes: it was 4 or 8 bytes, and it becomes 0 or 4 > bytes. At this point we're still correct. But very shortly after this, > on line 12205 we restore the oldpoint into the current point. Since we > just deleted stuff from the BEGINNING of the buffer, the oldpoint > doesn't point to the same thing as before. Restoring it directly is > wrong, but this normally doesn't cause crashes. The thing that causes > crashing is that sometimes the byte-char offset in oldpoint is no longer > correct, and we fail the consistency checks in redisplay_window(). I'm confused by the last part of your description. The code which resets point to 'oldpoint' is this: if (point_at_end) TEMP_SET_PT_BOTH (Z, Z_BYTE); else /* We can't do Fgoto_char (oldpoint) because it will run some Lisp code. */ TEMP_SET_PT_BOTH (marker_position (oldpoint), marker_byte_position (oldpoint)); IOW, it uses 'oldpoint', which is a marker, not a simple number. It was initialized like this: oldpoint = message_dolog_marker1; set_marker_restricted_both (oldpoint, Qnil, PT, PT_BYTE); Since 'oldpoint' is a marker, it should have been moved by del_range_both so that it still points to the same text. Moreover, the char <-> byte correspondence was not supposed to be disrupted by that. So I think something else is at work here. Can you show the data you collected during the rr session? Specifically, what are the character and byte positions of 'oldpoint' before the call to del_range_both, how many characters and bytes were deleted by del_range_both, and what are the character and byte position of 'oldpoint' when we call TEMP_SET_PT_BOTH in the snippet I show above? One possibility is that the value of 'oldpoint' gets overwritten somehow between the place it is set and the place it is used to restore point. But in that case we need to find the code which overwrites it.