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#71274: 30.0.50; assertion failed: w->window_end_valid, in find_first_unchanged_at_end_row Date: Fri, 31 May 2024 14:11:49 +0300 Message-ID: <86plt2p762.fsf@gnu.org> References: <86le3rr0lm.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6372"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71274@debbugs.gnu.org To: Daniel Clemente Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 31 13:13:15 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 1sD0CA-0001Ta-PV for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 31 May 2024 13:13:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sD0Bp-0007Un-7R; Fri, 31 May 2024 07:12:53 -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 1sD0Bn-0007UP-9X for bug-gnu-emacs@gnu.org; Fri, 31 May 2024 07:12: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 1sD0Bn-0001XD-0q for bug-gnu-emacs@gnu.org; Fri, 31 May 2024 07:12:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sD0Bx-0000XM-RZ for bug-gnu-emacs@gnu.org; Fri, 31 May 2024 07:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 31 May 2024 11:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71274 X-GNU-PR-Package: emacs Original-Received: via spool by 71274-submit@debbugs.gnu.org id=B71274.17171539312007 (code B ref 71274); Fri, 31 May 2024 11:13:01 +0000 Original-Received: (at 71274) by debbugs.gnu.org; 31 May 2024 11:12:11 +0000 Original-Received: from localhost ([127.0.0.1]:53314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sD0B9-0000WG-C3 for submit@debbugs.gnu.org; Fri, 31 May 2024 07:12:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sD0B8-0000Vz-3x for 71274@debbugs.gnu.org; Fri, 31 May 2024 07:12:10 -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 1sD0Aq-0001PS-Hg; Fri, 31 May 2024 07:11:53 -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=FHibdEUA5oTHhKpPOKwm/YAuFi7oXBNeVA5ZEum8gKY=; b=BcYF3VCc7KIJ vojNiOKYHtMJRvspRXJgMoonIG2R+tLP2RPetEIt5wrYp62QSks0YZ/h8ybGS4/n1nJI+8Vc5I6ur nBCXcrQyFw5PZi1h+oT+bsr4DEL7hYuggiSM+649j0y36SeTpPPRNQxzKqEQSyKPY+b7R/sO66R7H YtVnRoJuVRPxUA9Ki934O3okpVnjtu6jE895ERHKetcBA6mbSLkdm8bpOWaw/WfRkETA48YZFmOVu RIp7iFrJnOI13wN+4P4JB3WCy8ZJIH+UsWkILgv/5yuB+87yJyf7uLs5xxsI1Kg7CDbu8GZKT+KxM 8bWnW+ydpiDMnUB5zyiT8g==; In-Reply-To: (message from Daniel Clemente on Fri, 31 May 2024 10:08:18 +0000) 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:286272 Archived-At: > From: Daniel Clemente > Date: Fri, 31 May 2024 10:08:18 +0000 > Cc: 71274@debbugs.gnu.org > > > However, find_first_unchanged_at_end_row is called from try_window_id: > > > #3 0x00005555555de527 in try_window_id (w=0x5555622c4f68) at xdisp.c:22347 > > And that function already checked that w->window_end_valid is > > non-zero, several dozens of lines before that: > > /* Verify that display wasn't paused. */ > > if (!w->window_end_valid) > > GIVE_UP (8); > > Between this check (the one "several dozens of lines before that"), > and the call to find_first_unchanged_at_end_row, something has the > side effect of changing window_end_valid to false. In particular: > > > if (last_unchanged_at_beg_row) > { > /* Avoid starting to display in the middle of a character, a TAB > for instance. This is easier than to set up the iterator > exactly, and it's not a frequent case, so the additional > effort wouldn't really pay off. */ > while ((MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (last_unchanged_at_beg_row) > || last_unchanged_at_beg_row->ends_in_newline_from_string_p) > && last_unchanged_at_beg_row > w->current_matrix->rows) > --last_unchanged_at_beg_row; > > if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (last_unchanged_at_beg_row)) > GIVE_UP (17); > > if (! init_to_row_end (&it, w, last_unchanged_at_beg_row)) > GIVE_UP (18); > > > Before that last init_to_row_end, w->window_end_valid was true, and, > after it, it was false. Thanks, but please find where it changes inside the call to init_to_row_end, because I couldn't see anything obvious in the code involved in that call. There's some factor at work here that we need to identify and understand. (It is easy to add some band-aid without such an understanding, but I'm not yet prepared to do that.) > I saw it through fprintfs added before and after the line. > It's not always like that; sometimes it just stays true all through. I > still don't know the conditions to reproduce this, but I have seen > this bug 4 or 5 times yesterday+today. > > So it must be a side effect of init_to_row_end. Yes, but where exactly in that function or the ones it calls? > By the way, could this comment in try_window_id explain what is > happening? Maybe this part needs to be moved earlier. Maybe. But I'd like to see a backtrace with some of those guilty parties in the callstack, before I do that.