[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using clien
From: |
Mark Oteiza |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mark Oteiza <mvoteiza@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.
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux, Mark Oteiza, 2014/02/06
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux, Eli Zaretskii, 2014/02/07
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux, Mark Oteiza, 2014/02/07
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux, Eli Zaretskii, 2014/02/08
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux,
Mark Oteiza <=
- bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux, Eli Zaretskii, 2014/02/09