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: Tue, 30 Jul 2024 19:21:17 +0300 Message-ID: <86sevqyhoi.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> <86cymwzaj3.fsf@gnu.org> <87jzh4tlal.fsf@secretsauce.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33244"; 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 Tue Jul 30 18:22:01 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 1sYpbr-0008FQ-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Jul 2024 18:22:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYpbi-0007z3-G3; Tue, 30 Jul 2024 12:21:50 -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 1sYpbg-0007ys-VV for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2024 12:21:49 -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 1sYpbg-0003Tv-N6 for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2024 12:21:48 -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=4tc4IbaCQL+e62PM2Y56ht6qGV2gk8yTEYnEDLxddp8=; b=eXL85CRbTxK848NlJT+IXvpyx4aKIBzE4N+wKDO/4sH3chRIPIRhlP9s/qWg31LkDtg83e+fPwuH5OeuOZ5YiKJIuQaL4hTGZ/xcq7EClJ0oMd1xIfgreBF1118glrLgCA69IPj460ZHz5NI01aQFjIKjTVQjnFc/Kb/1QRT24Nvi2knSlkZdTEWKnLELXssTTwYzLoVMQ81pT11xyh6k4f6gvvyYAR/OT0VjVkxGeQuOPZ4FBQsCyGAu5jejttnZHFBCS1wUa6qHjQprzOujMhEQxqR5Dr7R55lNEQ+dOzJLnsXUFS7yHVT2O+rZJEx052jo8y32P9DlJ7JDaHV2w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sYpbu-0001Gp-HL for bug-gnu-emacs@gnu.org; Tue, 30 Jul 2024 12:22: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: Tue, 30 Jul 2024 16:22: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.17223565044860 (code B ref 72165); Tue, 30 Jul 2024 16:22:02 +0000 Original-Received: (at 72165) by debbugs.gnu.org; 30 Jul 2024 16:21:44 +0000 Original-Received: from localhost ([127.0.0.1]:48305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYpbb-0001GK-Q3 for submit@debbugs.gnu.org; Tue, 30 Jul 2024 12:21:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYpbY-0001G8-Sa for 72165@debbugs.gnu.org; Tue, 30 Jul 2024 12:21:41 -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 1sYpbF-0003SB-5S; Tue, 30 Jul 2024 12:21:21 -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=4tc4IbaCQL+e62PM2Y56ht6qGV2gk8yTEYnEDLxddp8=; b=Ekb9Z3AtzEkf BQMyzGdFr1n9LdKqA8x0K/rPUGQxikb7eT/5m3P5JxLCKD1JcqptGwlmxPjf13V1g6oAOJPUNCkTg ZelBUAk6d+BbcJIrxBPLvqboMf5Vj1A5LNnBSeOY45uFsUSMbWaN6ySVcgC8TYju4Qhc+BJlozSnG a60qppKs1MxXzn8qfUV6FrCfyOWqKzS9X6FcVTnIju0FvSAIvFpGkcGKEkw3IJXA5o11BiTid6Z28 jU6gJFxgAJXWmo/fsER5OnV4VG5rmWr4QiRIVxxGCrCHvVfukhD2zHTfBVPw/0Z+p9q04LChZEQLf Vjgp0xxamXZbqTGsFzAhtw==; In-Reply-To: <87jzh4tlal.fsf@secretsauce.net> (message from Dima Kogan on Mon, 29 Jul 2024 05:49:54 -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:289554 Archived-At: > From: Dima Kogan > Cc: 72165@debbugs.gnu.org > Date: Mon, 29 Jul 2024 05:49:54 -0700 > > - I'm at the top of redisplay_window() that has a crashing state, right > after a redisplay_window() cycle with a non-crashing state. The > crashing state has z_byte-z = 8 but pt_byte-pt = 12. Both are at the > end of the buffer, and 8 is the correct value. > > - I run backwards until the truncation in message_dolog(): > > 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); > } > > Right after this both z_byte-z=8 (correct) and the point is at the > beginning. This is correct, and the truncation itself didn't break > anything. Note: this was (eventually) called from redisplay_window(), > in the display_mode_lines() call in xdisp.c:20941 > > - Then we restore the oldpoint; what I suggested was the problem > previously: > > 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)); > > After that, both z_byte-z and pt_byte-pt are 8. This is correct. > > - Then we do this, in redisplay_window() in xdisp.c:21908 > > /* Restore current_buffer and value of point in it. The window > update may have changed the buffer, so first make sure `opoint' > is still valid (Bug#6177). */ > if (CHARPOS (opoint) < BEGV) > TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE); > else if (CHARPOS (opoint) > ZV) > TEMP_SET_PT_BOTH (Z, Z_BYTE); > else > TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint)); > > We pick the "else" branch. The end result is the exact failing state > we hit on the next pass through redisplay_window(). > > > This sounds like a different flavor of what I described yesterday. So in > summary: in a redisplay_window() call: > > - We set the opoint on line 20064. This is a text_pos, NOT a marker. So > it wouldn't be updated due to the buffer changing. > > - On line 20941 we call display_mode_lines() which eventually deletes > lines at the start of *Messages* and moves the point. > > - On line 21908 we restore the opoint, saved prior to the lines being > deleted, and no longer valid So let me see if I understand you correctly regarding what happens: . The *Messages* buffer is displayed in a window, which is redisplayed, and the display engine calls redisplay_window for it. . redisplay_window records the original position of point in the *Messages* buffer, then calls display_mode_lines, as it does for any window whose mode line needs to be redrawn for some reason . somewhere inside display_mode_lines, we call message_dolog, most probably because the mode-line format calls :eval, which signals an error . message_dolog adds some text to *Messages* and removes some other text from it, which invalidates the position of point recorded at the beginning of redisplay_window . redisplay_window then uses invalid value of point (including its byte position, which no longer corresponds to the character position) to set point, and that opens the gates of hell Is that correct? If so, this puzzle has the following pieces: . *Messages* is displayed and includes non-ASCII text . mode-line-format that signals an error when the window showing *Messages* is redisplayed . the size of *Messages* buffer and its contents are such that moving point to the value recorded at entry to redisplay_window produces a mismatch between PT and PT_BYTE If all of the above happen, we are toast. Right? Can you verify that the above theory is true? For example does CHARS_MODIFF value of the buffer after display_mode_lines returns differ from its value before the call?