bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50096: args-out-of-range in redisplay_internal


From: Eli Zaretskii
Subject: bug#50096: args-out-of-range in redisplay_internal
Date: Wed, 18 Aug 2021 15:18:29 +0300

> From: Juri Linkov <juri@linkov.net>
> Cc: 50096@debbugs.gnu.org
> Date: Wed, 18 Aug 2021 10:42:23 +0300
> 
> >> (gdb) xstring
> >> $8 = (struct Lisp_String *) 0x7f015341fb80
> >> " *Minibuf-0*"
> >
> > Hm... something else is at work here.
> 
> 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.

> The steps are following:
> 
> 1. message3_nolog calls echo_area_display
> 2. echo_area_display calls redisplay_internal
> 3. redisplay_internal clears all matrices with clear_desired_matrices
> 4. redisplay_internal calls echo_area_display
>    that temporarily changes mini_window's buffer
>    from " *Minibuf-0*" to " *Echo Area 0*".
>    This updates w->desired_matrix to contain information
>    about " *Echo Area 0*" displayed in the mini_window.
>    But unwind_with_echo_area_buffer immediately
>    changes mini_window's buffer back to empty " *Minibuf-0*".
> 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?  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.

> > 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]