GNU bug report logs - #50096
args-out-of-range in redisplay_internal

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 17 Aug 2021 16:09:02 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 50096 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50096 <at> debbugs.gnu.org
Subject: Re: bug#50096: args-out-of-range in redisplay_internal
Date: Wed, 18 Aug 2021 19:32:01 +0300
>> I don't understand how this is supposed to work.  The buffer " *Minibuf-0*"
>> is always empty at the time of calling message3_nolog, whereas the buffer
>> " *Echo Area 0*" contains the message to display.
>
> Yes, some code switches to another buffer at the wrong moment.

There are no buffer switching involved neither in the successful case
nor in the failing case.

>> 5. redisplay_internal calls hscroll_window_tree
>>    where cursor_row already contains information
>>    that was valid when " *Echo Area 0*" was temporarily
>>    displayed in mini_window:
>
> Any idea why we call hscroll_window_tree in this case?

Here are all differences in cursor_row between success and failure:

@@ -1,8 +1,8 @@
 (gdb) p *cursor_row
 {
   x = 0,
   y = 228,
-  pixel_width = 1610,
+  pixel_width = 1910,
   ascent = 15,
   height = 19,
   phys_ascent = 12,
@@ -26,8 +26,8 @@
   },
   end = {
     pos = {
-      charpos = 1897,
-      bytepos = 1897
+      charpos = 2150,
+      bytepos = 2150
     },
     overlay_string_index = -1,
     string_pos = {
@@ -41,14 +41,14 @@
     bytepos = 1737
   },
   maxpos = {
-    charpos = 1897,
-    bytepos = 1897
+    charpos = 2150,
+    bytepos = 2150
   },
   overlay_arrow_bitmap = 0,
   left_user_fringe_bitmap = 0,
   right_user_fringe_bitmap = 0,
   left_fringe_bitmap = 0,
-  right_fringe_bitmap = 0,
+  right_fringe_bitmap = 31,
   left_user_fringe_face_id = 0,
   right_user_fringe_face_id = 0,
   left_fringe_face_id = 0,
@@ -59,7 +59,7 @@
   redraw_fringe_bitmaps_p = true,
   enabled_p = true,
   truncated_on_left_p = false,
-  truncated_on_right_p = false,
+  truncated_on_right_p = true,
   continued_p = false,
   displays_text_p = true,
   ends_at_zv_p = true,

When it fails, truncated_on_right_p is true, that causes
executing code block with init_to_row_start in hscroll_window_tree,
that fails with truncated long miniwindow lines.

In the successful case truncated_on_right_p=false allows
hscroll_window_tree to skip the block with init_to_row_start,
and other hscrolling.

> I'm guessing this is due to some customizations of yours, in which
> case I'd appreciate a reproduction recipe starting from "emacs -Q".
> It is very hard to debug such problems via email.

It's 100% reproducible for me, but I'm not sure how easy would be
to create a test case for "emacs -Q".

>> > You are saying that if you remove the ":(literal)" part without
>> > changing anything else, the problem goes away?
>>
>> Indeed, it broke after the commit 3572613550.
>> But after applying this patch it works again without errors:
>
> Does this patch work by preventing hscrolling?
>
>> I guess additional ":(literal)" string increases the length
>> of the displayed message, and longer message triggers the bug.
>
> How does it trigger it? via hscrolling or some other way?

It reduces the length of the displayed message,
so there is no wrapped line and no hscrolling.




This bug report was last modified 3 years and 275 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.