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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50096 <at> debbugs.gnu.org
Subject: bug#50096: args-out-of-range in redisplay_internal
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.  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:

(gdb) l
14896		    cursor_row = MATRIX_ROW (w->desired_matrix, w->cursor.vpos);
(gdb) p *cursor_row
...
  start = {
    pos = {
      charpos = 1737,
      bytepos = 1737
    },
...
  end = {
    pos = {
      charpos = 2150,
      bytepos = 2150

These numbers are valid positions in " *Echo Area 0*"
that was temporarily displayed in mini_window,
but now mini_window's buffer is empty " *Minibuf-0*".

>> PS: Some commit between e2eb58c487 and 31ab12e261 broke that,
>> but maybe this is not important because these commits
>> just changed the length of the git command by adding ":(literal)",
>> and length change maybe exposed some other problem.
>
> 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:

diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index ffe1e6832c..0bea987a06 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -950,7 +950,7 @@ vc-git-checkin
                (lambda (value) (when (equal value "yes") (list argument)))))
       ;; When operating on the whole tree, better pass "-a" than ".", since "."
       ;; fails when we're committing a merge.
-      (apply #'vc-git-command nil 0 (if only (vc-git--literal-pathspecs files))
+      (apply #'vc-git-command nil 0 (if only files)
              (nconc (if msg-file (list "commit" "-F"
                                        (file-local-name msg-file))
                       (list "commit" "-m"))

I guess additional ":(literal)" string increases the length
of the displayed message, and longer message triggers the bug.

Previous Next

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