bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Mark Oteiza]

Reproducible on my system with tmux 1.9a:

1. emacs --daemon -Q
2. Start tmux in a term emulator and invoke `emacsclient -t` in
   the tmux window
3. Do `C-x 3` in the client
4. Split horizontally the tmux window into two panes: <prefix> "
5. Open a new emacsclient in the new pane, exit the client (^X^C),
   and close the new tmux pane (^D)
6. Interact with the first client.

Attaching with gdb the first time:

find_interval (tree=0xed9198, position=732) at intervals.c:681
681     in intervals.c
(gdb) s
683     in intervals.c
(gdb) s
701     in intervals.c
(gdb) s
681     in intervals.c
(gdb) s
683     in intervals.c
(gdb) s
701     in intervals.c

Otherwise, setting a breakpoint at find_interval and continuing,
`position` changes value but I always end up back at find_interval.



In GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2014-07-24 on holos
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64
 -mtune=generic -O0 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4 -g -fvar-tracking-assignments'
 LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  flycheck-mode: t
  company-mode: t
  winner-mode: t
  show-paren-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
ESC [ > 0 ; 9 5 ; 0 c ESC x r e p o - e m - b TAB 
RET

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs/24.4.50/lisp/loaddefs hides /home/mvo/.emacs.d/site-lisp/loaddefs

Features:
(shadow sort gnus-util mail-extr emacsbug message idna dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils xterm flycheck find-func
help-mode easymenu rx f dash s company-files company-oddmuse
company-keywords company-etags etags company-gtags company-dabbrev-code
company-dabbrev company-capf company-cmake company-ropemacs
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company pcase
easy-mmode cl-macs gv package windmove edmacro kmacro cl-loaddefs cl-lib
saveplace winner ring time-date paren zenburn-theme tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 16 130940 8879)
 (symbols 48 21621 0)
 (miscs 40 46 141)
 (strings 32 22838 6984)
 (string-bytes 1 615107)
 (vectors 16 17827)
 (vector-slots 8 1133415 211358)
 (floats 8 92 595)
 (intervals 56 205 0)
 (buffers 960 11)
 (heap 1024 46183 1194))

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 25 Jul 2014 19:08:43 -0400
> 
> 1. emacs --daemon -Q
> 2. Start tmux in a term emulator and invoke `emacsclient -t` in
>    the tmux window
> 3. Do `C-x 3` in the client
> 4. Split horizontally the tmux window into two panes: <prefix> "
> 5. Open a new emacsclient in the new pane, exit the client (^X^C),
>    and close the new tmux pane (^D)
> 6. Interact with the first client.
> 
> Attaching with gdb the first time:
> 
> find_interval (tree=0xed9198, position=732) at intervals.c:681
> 681     in intervals.c
> (gdb) s
> 683     in intervals.c
> (gdb) s
> 701     in intervals.c
> (gdb) s
> 681     in intervals.c
> (gdb) s
> 683     in intervals.c
> (gdb) s
> 701     in intervals.c
> 
> Otherwise, setting a breakpoint at find_interval and continuing,
> `position` changes value but I always end up back at find_interval.

Thanks.

Please use the procedure in etc/DEBUG to find out where it loops.  The
procedure calls for using the "finish" command until some frame
doesn't return, then stepping with "next" through that frame to see
where and why it loops.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 26 Jul 2014 09:42:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
> 
> Please use the procedure in etc/DEBUG to find out where it loops.  The
> procedure calls for using the "finish" command until some frame
> doesn't return, then stepping with "next" through that frame to see
> where and why it loops.

The loop is in redisplay, and the reason seems to be that get_tty_size
returns incorrect size after the second tmux pane is closed with ^D.
We get one line more than tmux leaves us (after usurping 1 line for
its status line).

I don't know enough about TIOCGWINSZ ioctl to tell how to fix this,
sorry.  Perhaps some termio expert could chime in.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't know enough about TIOCGWINSZ ioctl to tell how to fix this,
> sorry.  Perhaps some termio expert could chime in.

If TIOCGWINSZ disagrees with the actual size of the terminal then the
bug is in tmux in that it sets the wrong size.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.
> We get one line more than tmux leaves us (after usurping 1 line for
> its status line).

Does get_tty_size actually look at the correct terminal (the one
connected to the tty frame)?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mvoteiza@udel.edu,  18112@debbugs.gnu.org
> Date: Sat, 26 Jul 2014 10:15:58 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The loop is in redisplay, and the reason seems to be that get_tty_size
> > returns incorrect size after the second tmux pane is closed with ^D.
> > We get one line more than tmux leaves us (after usurping 1 line for
> > its status line).
> 
> Does get_tty_size actually look at the correct terminal (the one
> connected to the tty frame)?

See handle_window_change_signal: we loop through all the tty's, and
call get_tty_size for each one of them.

If this doesn't answer the question, please tell how to check that the
terminal is the correct one, and I will take a look.

Thanks.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 26 Jul 2014 10:55:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
> 
> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.
> We get one line more than tmux leaves us (after usurping 1 line for
> its status line).

Actually, I think I was wrong (I forgot to count the line used for the
menu bar).  So the reason is probably elsewhere...

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 26 Jul 2014 12:04:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
> 
> > Date: Sat, 26 Jul 2014 10:55:11 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 18112@debbugs.gnu.org
> > 
> > The loop is in redisplay, and the reason seems to be that get_tty_size
> > returns incorrect size after the second tmux pane is closed with ^D.
> > We get one line more than tmux leaves us (after usurping 1 line for
> > its status line).
> 
> Actually, I think I was wrong (I forgot to count the line used for the
> menu bar).  So the reason is probably elsewhere...

Ok, my original analysis was based on a mistake.  Moreover, tmux is
not really related to the problem at all, and neither is "C-x 3".

Here's a simpler way to reproduce the problem:

Open a terminal emulator (e.g., xterm) window, and in that window:

  emacs -Q --daemon
  emacsclient -t

Now open another terminal emulator window, and make it have a smaller
size.  Then, in that window:

  emacsclient -t
  C-x C-c

Now go back to the first xterm window and resize it (e.g., with a
mouse).  Emacs is now stuck in an infloop.

So the important players here are (1) a frame on another tty that has
a different size, and (2) resizing the frame after deleting another
frame on a different tty.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 26 Jul 2014 12:33:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
> 
> So the important players here are (1) a frame on another tty that has
> a different size, and (2) resizing the frame after deleting another
> frame on a different tty.

Fixed in revision 117409 on the emacs-24 branch.

(It's amazing what one 99%-correct line of Lisp can do.)

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

> (It's amazing what one 99%-correct line of Lisp can do.)

Indeed.  Thanks for fixing my 1% blindness.

martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sun, 27 Jul 2014 15:35:37 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> > (It's amazing what one 99%-correct line of Lisp can do.)
> 
> Indeed.  Thanks for fixing my 1% blindness.

You're welcome.

As long as I have your attention: how about adding some comments
and/or text to respective doc strings to explain what exactly the
following functions do, and why/when are they needed?

  window-normal-size
  window-new-total
  window-new-normal
  window-new-pixel

and the corresponding set-* functions.  Their doc strings are just
tautological repetition of their names, which isn't helpful.  And the
ELisp manual doesn't say a word about them, so the doc strings need to
do a better job, IMO.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

 > As long as I have your attention: how about adding some comments
 > and/or text to respective doc strings to explain what exactly the
 > following functions do, and why/when are they needed?
 >
 >    window-normal-size
 >    window-new-total
 >    window-new-normal
 >    window-new-pixel
 >
 > and the corresponding set-* functions.  Their doc strings are just
 > tautological repetition of their names, which isn't helpful.  And the
 > ELisp manual doesn't say a word about them, so the doc strings need to
 > do a better job, IMO.

I'll do that.

martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

 > As long as I have your attention: how about adding some comments
 > and/or text to respective doc strings to explain what exactly the
 > following functions do, and why/when are they needed?
 >
 >    window-normal-size
 >    window-new-total
 >    window-new-normal
 >    window-new-pixel
 >
 > and the corresponding set-* functions.  Their doc strings are just
 > tautological repetition of their names, which isn't helpful.  And the
 > ELisp manual doesn't say a word about them, so the doc strings need to
 > do a better job, IMO.

I've tried to do that now.  Please have a look.

Thanks, martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Fri, 08 Aug 2014 12:10:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
> 
>  > As long as I have your attention: how about adding some comments
>  > and/or text to respective doc strings to explain what exactly the
>  > following functions do, and why/when are they needed?
>  >
>  >    window-normal-size
>  >    window-new-total
>  >    window-new-normal
>  >    window-new-pixel
>  >
>  > and the corresponding set-* functions.  Their doc strings are just
>  > tautological repetition of their names, which isn't helpful.  And the
>  > ELisp manual doesn't say a word about them, so the doc strings need to
>  > do a better job, IMO.
> 
> I've tried to do that now.  Please have a look.

Thanks.  This is an improvement for the functions that deal with the
"normal" size (which should have been called "normalized", but I guess
that's water under the bridge now).

I see no improvement for the "total" size.  The additions to the doc
strings point to window-total-size, but that function's doc string
does not explain what is the semantics of "total" in this respect.
(The doc string of window-total-size references window-total-width and
window-total-height, which do say something about that, but having to
traverse more than 1 hyperlink to find the information is not a good
idea, IMO.)

Also, the way you document the *-new-* functions could be improved.
You say something like

  The new pixel size of WINDOW is used by `window-resize-apply' and, if
  that function succeeds, will be subsequently returned by the functions
  `window-pixel-height' and `window-pixel-width'.

I suggest instead to say something that describes the effect, but not
how the effect is achieved (which is low-level information that
obscures and obfuscates what the reader would like to know):

  The new pixel size of WINDOW, if it is valid, will be shortly
  installed as WINDOW's size.

Thanks.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

 > I see no improvement for the "total" size.  The additions to the doc
 > strings point to window-total-size, but that function's doc string
 > does not explain what is the semantics of "total" in this respect.
 > (The doc string of window-total-size references window-total-width and
 > window-total-height, which do say something about that, but having to
 > traverse more than 1 hyperlink to find the information is not a good
 > idea, IMO.)
 >
 > Also, the way you document the *-new-* functions could be improved.
 > You say something like
 >
 >    The new pixel size of WINDOW is used by `window-resize-apply' and, if
 >    that function succeeds, will be subsequently returned by the functions
 >    `window-pixel-height' and `window-pixel-width'.
 >
 > I suggest instead to say something that describes the effect, but not
 > how the effect is achieved (which is low-level information that
 > obscures and obfuscates what the reader would like to know):
 >
 >    The new pixel size of WINDOW, if it is valid, will be shortly
 >    installed as WINDOW's size.

I've tried to follow your advices.  Please have another look.

Thanks, martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 09 Aug 2014 13:14:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
> 
>  > I see no improvement for the "total" size.  The additions to the doc
>  > strings point to window-total-size, but that function's doc string
>  > does not explain what is the semantics of "total" in this respect.
>  > (The doc string of window-total-size references window-total-width and
>  > window-total-height, which do say something about that, but having to
>  > traverse more than 1 hyperlink to find the information is not a good
>  > idea, IMO.)
>  >
>  > Also, the way you document the *-new-* functions could be improved.
>  > You say something like
>  >
>  >    The new pixel size of WINDOW is used by `window-resize-apply' and, if
>  >    that function succeeds, will be subsequently returned by the functions
>  >    `window-pixel-height' and `window-pixel-width'.
>  >
>  > I suggest instead to say something that describes the effect, but not
>  > how the effect is achieved (which is low-level information that
>  > obscures and obfuscates what the reader would like to know):
>  >
>  >    The new pixel size of WINDOW, if it is valid, will be shortly
>  >    installed as WINDOW's size.
> 
> I've tried to follow your advices.  Please have another look.

Thanks, the *-new-* functions are now clearly documented.

The issue with window-total-size is still there, though.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

 > The issue with window-total-size is still there, though.

Which one?  Should I copy the descriptions from `window-total-height'
and `window-total-width' to the doc-string of `window-total-size'?

martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sat, 09 Aug 2014 17:56:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
> 
>  > The issue with window-total-size is still there, though.
> 
> Which one?  Should I copy the descriptions from `window-total-height'
> and `window-total-width' to the doc-string of `window-total-size'?

I think just saying what "total" includes, and how it differs from
the corresponding non-"total" dimensions, should be good enough.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[martin rudalics]

> I think just saying what "total" includes, and how it differs from
> the corresponding non-"total" dimensions, should be good enough.

I tried to do that.

Thanks, martin

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> Date: Sun, 10 Aug 2014 12:42:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
> 
> > I think just saying what "total" includes, and how it differs from
> > the corresponding non-"total" dimensions, should be good enough.
> 
> I tried to do that.

Thanks, I'm happy now.

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.

Does it?  I don't see that here.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Andreas Schwab]

We never trigger redisplay after do_pending_window_change in
wait_reading_process_output.  Why?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mvoteiza@udel.edu,  18112@debbugs.gnu.org
> Date: Sat, 26 Jul 2014 11:44:13 +0200
> 
> We never trigger redisplay after do_pending_window_change in
> wait_reading_process_output.  Why?

Probably because redisplay calls do_pending_window_change at its very
beginning.

I also don't see how would triggering redisplay earlier fix the
problem at hand.  Am I missing something?

bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: mvoteiza@udel.edu,  18112@debbugs.gnu.org
>> Date: Sat, 26 Jul 2014 11:44:13 +0200
>> 
>> We never trigger redisplay after do_pending_window_change in
>> wait_reading_process_output.  Why?
>
> Probably because redisplay calls do_pending_window_change at its very
> beginning.

What does this have to do with the call in wait_reading_process_output?
Since it doesn't return until the next keypress we have a non-updated
display for a potentially long time.

> I also don't see how would triggering redisplay earlier fix the
> problem at hand.  Am I missing something?

It may be part of the problem, who knows.  You missed a lot in this
thread already, didn't you?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."