bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 07 Feb 2014 11:06:40 -0500
> 
> > Also, what are "client-daemon" and "tmux", and how are they related to
> > Emacs?
> 
> I have only been able to do this using the emacs daemon and
> emacsclients.  I think tmux has something to do with it because it is
> possible to manipulate the size of emacsclient frames without them being
> focused.  I will try to describe it:
> 
> Here I have a single terminal emulator running tmux.  An emacs daemon is
> running and I start emacsclient "A".
> 
> | A |
> 
> In tmux I vertically split the window, so "A" is in the left pane, a new
> shell is in the right.  "A" has focus until I start a new client "B" in
> the right.
> 
> |A| |
> 
> |A|B|
> 
> Now, "B" has focus. I exit from this client into the shell, and exit the
> shell, killing the tmux pane.  At this point, the pane "A" occupies is
> the sole pane, but "A" is still only occupying half the window!
> 
> |A  |
> 
> I can make and destroy tmux panes and constrict the client
> "display". The frame won't update until I enter the pane "A" occupies
> *and* interact with the client.

Sounds like Emacs is not being told about these changes.  Do they send
the SIGWINCH signal?  If not, how is Emacs supposed to know about
them?

> This does not happen in 24.3, so this is a regression I imagine I can
> bisect if need be.

Please do, and thanks.

> I took `curY (tty) >= FrameRows (tty) - 1` as a hint, and figured I
> could make emacs crash by doing horizontal splits and messing with the
> focus and term emulator window size, so emacsclients were out of focus
> and displaying the wrong number of rows.  I'm not sure of an EXACT
> process to reproduce, but I got a couple crashes pretty quickly by
> mixing up these actions.

If Emacs is confused about its frame size, a crash is imminent.

> #3  0x00000000004e6bc5 in cmcheckmagic (tty=0xcab010) at cm.c:120
> No locals.
> #4  0x00000000004e9ac9 in tty_write_glyphs (f=0x1251078, 
> string=0x7fa611599760, len=149) at term.c:778
>         conversion_buffer = 0x1ae6410 ' ' <repeats 177 times>, "\f\001  `(i!"
>         coding = 0x19a9ab0
>         n = 149
>         stringlen = 0
>         tty = 0xcab010
> #5  0x00000000004f2fcb in write_glyphs (f=0x1251078, string=0x7fa611597b70, 
> len=149) at terminal.c:162
> No locals.
> #6  0x000000000041c56c in update_frame_line (f=0x1251078, vpos=50) at 
> dispnew.c:4791
>         obody = 0x0
>         nbody = 0x7fa611597b70
>         op1 = 0x29
>         op2 = 0x412d30 <_start>
>         np1 = 0x7fffa4cf9e10
>         nend = 0x7fa611599760
>         tem = 4290101
>         osp = 2
>         nsp = 14045808
>         begmatch = 0
>         endmatch = 291518304
>         olen = 0
>         nlen = 149
>         current_matrix = 0xcef6f0
>         desired_matrix = 0x143c2f0
>         current_row = 0xecedd0
>         desired_row = 0xf01cc0
>         must_write_whole_line_p = true
>         write_spaces_p = true
>         colored_spaces_p = true

This seems to indicate that Emacs thinks its frame is 149-column wide
and 51-row high.  Does this make sense?