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

Previous Next

Full log

View this message in rfc822 format

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: 16674 <at> debbugs.gnu.org
Subject: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
Date: Sun, 09 Feb 2014 02:39:09 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Mark Oteiza <mvoteiza <at> udel.edu>
>> Date: Fri, 07 Feb 2014 11:06:40 -0500
>> 
>> |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?

Ok, in this example, no SIGWINCH is sent when "B" is closed and the pane
it occupied (stracing client "A").

It seems like when the focused client is killed, no other client gets
"updated" until some input happens; either mouse click with
xterm-input-mode or keyboard input.

>> 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 found 0cd28af (references Bug#15025).

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

177x51 is the size of a full screen tmux window for me, so it makes sense.

Previous Next

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