Package: emacs;
Reported by: Mark Oteiza <mvoteiza <at> udel.edu>
Date: Thu, 6 Feb 2014 21:25:02 UTC
Severity: normal
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16674 in the body.
You can then email your comments to 16674 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Thu, 06 Feb 2014 21:25:02 GMT) Full text and rfc822 format available.Mark Oteiza <mvoteiza <at> udel.edu>
:bug-gnu-emacs <at> gnu.org
.
(Thu, 06 Feb 2014 21:25:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Thu, 06 Feb 2014 16:25:07 -0500
[Message part 1 (text/plain, inline)]
Hi, I have had several similar crashes over the past couple weeks, using the daemon and a variety of clients in and out of tmux sessions. I attached the backtrace the most recent crash. Mark
[emacs_btfull06feb.txt (text/plain, inline)]
Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50 [master* ~/13F/pf]$ sudo systemd-coredumpctl gdb 610 TIME PID UID GID SIG EXE Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50 GNU gdb (GDB) 7.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/emacs-24.3.50...done. warning: core file may not match specified executable file. [New LWP 610] [New LWP 614] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff19d68000 Core was generated by `emacs --daemon'. Program terminated with signal 6, Aborted. #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 (gdb) bt #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 #1 0x00000000004db076 in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378 #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127 #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120 #4 0x000000000041793b in update_frame_line (f=f <at> entry=0x12996e8, vpos=50) at dispnew.c:4791 #5 0x000000000041af74 in update_frame_1 (f=f <at> entry=0x12996e8, force_p=force_p <at> entry=true, inhibit_id_p=inhibit_id_p <at> entry=false) at dispnew.c:4461 #6 0x000000000041caeb in update_frame (f=f <at> entry=0x12996e8, force_p=<optimized out>, force_p <at> entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p <at> entry=false) at dispnew.c:3073 #7 0x0000000000449da7 in redisplay_internal () at xdisp.c:13665 #8 0x000000000044bba0 in redisplay_preserve_echo_area (from_where=from_where <at> entry=11) at xdisp.c:13879 #9 0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=12110066, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=just_wait_proc <at> entry=0) at process.c:4531 #10 0x00000000004e23c7 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=<optimized out>, kbp=<synthetic pointer>) at keyboard.c:3894 #11 read_event_from_main_queue (used_mouse_menu=<optimized out>, local_getcjmp=<optimized out>, end_time=0x0) at keyboard.c:2239 #12 read_decoded_event_from_main_queue (end_time=end_time <at> entry=0x0, local_getcjmp=local_getcjmp <at> entry=0x7fff19cc4510, prev_event=prev_event <at> entry=12110066, used_mouse_menu=used_mouse_menu <at> entry=0x7fff19cc479b) at keyboard.c:2302 #13 0x00000000004e66af in read_char (commandflag=1, map=map <at> entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu <at> entry=0x7fff19cc479b, end_time=end_time <at> entry=0x0) at keyboard.c:2888 #14 0x00000000004e7463 in read_key_sequence (keybuf=keybuf <at> entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false, bufsize=30) at keyboard.c:9071 #15 0x00000000004e9080 in command_loop_1 () at keyboard.c:1445 #16 0x0000000000549d6e in internal_condition_case (bfun=bfun <at> entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun <at> entry=0x4dfe30 <cmd_error>) at eval.c:1345 #17 0x00000000004db4de in command_loop_2 (ignore=ignore <at> entry=12110066) at keyboard.c:1170 #18 0x0000000000549c7b in internal_catch (tag=12157474, func=func <at> entry=0x4db4c0 <command_loop_2>, arg=12110066) at eval.c:1109 #19 0x00000000004dfa57 in command_loop () at keyboard.c:1149 #20 recursive_edit_1 () at keyboard.c:777 #21 0x00000000004dfd42 in Frecursive_edit () at keyboard.c:841 #22 0x0000000000413c55 in main (argc=<optimized out>, argv=0x7fff19cc4bc8) at emacs.c:1643 (gdb) bt full #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 No symbol table info available. #1 0x00000000004db076 in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378 No locals. #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127 No locals. #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120 No locals. #4 0x000000000041793b in update_frame_line (f=f <at> entry=0x12996e8, vpos=50) at dispnew.c:4791 obody = <optimized out> nbody = 0x7f76a3f29b70 op1 = <optimized out> op2 = <optimized out> np1 = <optimized out> nend = <optimized out> tem = <optimized out> osp = <optimized out> nsp = <optimized out> begmatch = <optimized out> endmatch = <optimized out> olen = 0 nlen = 79 current_row = 0x2c68240 desired_row = <optimized out> must_write_whole_line_p = true write_spaces_p = <optimized out> colored_spaces_p = <optimized out> #5 0x000000000041af74 in update_frame_1 (f=f <at> entry=0x12996e8, force_p=force_p <at> entry=true, inhibit_id_p=inhibit_id_p <at> entry=false) at dispnew.c:4461 current_matrix = 0x2a4ef70 desired_matrix = 0x2b2a4f0 i = <optimized out> pause_p = <optimized out> preempt_count = 17 #6 0x000000000041caeb in update_frame (f=f <at> entry=0x12996e8, force_p=<optimized out>, force_p <at> entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p <at> entry=false) at dispnew.c:3073 paused_p = <optimized out> #7 0x0000000000449da7 in redisplay_internal () at xdisp.c:13665 gcscrollbars = <optimized out> w = <optimized out> sw = <optimized out> pending = <optimized out> must_finish = <optimized out> match_p = <optimized out> tlbufpos = <optimized out> tlendpos = <optimized out> number_of_visible_frames = <optimized out> sf = <optimized out> polling_stopped_here = 1 tail = 45575638 consider_all_windows_p = <optimized out> update_miniwindow_p = false ---Type <return> to continue, or q <return> to quit--- #8 0x000000000044bba0 in redisplay_preserve_echo_area (from_where=from_where <at> entry=11) at xdisp.c:13879 No locals. #9 0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=12110066, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=just_wait_proc <at> entry=0) at process.c:4531 timeout_reduced_for_timers = false channel = <optimized out> nfds = <optimized out> Available = {fds_bits = {992, 0 <repeats 15 times>}} Writeok = {fds_bits = {0 <repeats 16 times>}} check_write = true check_delay = 0 no_avail = <optimized out> xerrno = 4 proc = <optimized out> timeout = {tv_sec = 100000, tv_nsec = 0} wait_channel = -1 got_some_input = false #10 0x00000000004e23c7 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=<optimized out>, kbp=<synthetic pointer>) at keyboard.c:3894 do_display = <optimized out> obj = <optimized out> #11 read_event_from_main_queue (used_mouse_menu=<optimized out>, local_getcjmp=<optimized out>, end_time=0x0) at keyboard.c:2239 c = <optimized out> save_jump = {{__jmpbuf = {44877984, 46645184, 0, 1, 19502824, 4311824, 18914848, 19502824}, __mask_was_saved = 1, __saved_mask = {__val = {0, 18914853, 5844648, 8192, 5844648, 8192, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}} kb = <optimized out> #12 read_decoded_event_from_main_queue (end_time=end_time <at> entry=0x0, local_getcjmp=local_getcjmp <at> entry=0x7fff19cc4510, prev_event=prev_event <at> entry=12110066, used_mouse_menu=used_mouse_menu <at> entry=0x7fff19cc479b) at keyboard.c:2302 terminal = <optimized out> events = {0, 46576294, 140733626204896, 140733626878681, 140733626205056, 4307077362, 140733626205056, 20085296, 13878432, 5677, 16925, 140147731967853, 0, 6075762, 14257168, 12110066} n = <optimized out> #13 0x00000000004e66af in read_char (commandflag=1, map=map <at> entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu <at> entry=0x7fff19cc479b, end_time=end_time <at> entry=0x0) at keyboard.c:2888 c = <optimized out> local_getcjmp = {{__jmpbuf = {43912192, 8350626081242229992, 20085296, 13878432, 5677, 46521494, -8350425976639968024, 8350624602771959016}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 44046464, 5497916, 12142546, 44046464, 0, 16207264, 16485968, 5477142, 2}}}} save_jump = {{__jmpbuf = {44877984, 46645184, 0, 1, 19502824, 4311824, 18914848, 19502824}, __mask_was_saved = 1, __saved_mask = {__val = {0, 18914853, 5844648, 8192, 5844648, 8192, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}} tem = <optimized out> save = <optimized out> previous_echo_area_message = 12110066 also_record = 12110066 reread = false polling_stopped_here = true orig_kboard = 0xd3c4a0 #14 0x00000000004e7463 in read_key_sequence (keybuf=keybuf <at> entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false, bufsize=30) at keyboard.c:9071 interrupted_kboard = 0xd3c4a0 interrupted_frame = 0x29e0c48 ---Type <return> to continue, or q <return> to quit--- key = <optimized out> used_mouse_menu = false echo_local_start = 0 last_real_key_start = <optimized out> keys_local_start = <optimized out> new_binding = <optimized out> t = <optimized out> echo_start = 0 keys_start = 0 current_binding = 46521494 first_event = 12110066 first_unbound = 31 mock_input = 0 fkey = {parent = 44988422, map = 44988422, start = 0, end = 0} keytran = {parent = 12089926, map = 12089926, start = 0, end = 0} indec = {parent = 44988438, map = 44988438, start = 0, end = 0} shift_translated = false delayed_switch_frame = 12110066 original_uppercase = 12232850 original_uppercase_position = -1 dummyflag = false starting_buffer = 0x2a01880 fake_prefixed_keys = 12110066 #15 0x00000000004e9080 in command_loop_1 () at keyboard.c:1445 cmd = <optimized out> keybuf = {96, 76, 196, 236, 200, 264, 140733626206576, 140733626206512, 12110066, 12110066, 140733626207168, 1, 46435926, 5559188, 12157426, 46435926, 8639745, 12110066, 46435926, 5111306, 140733626206512, 46435926, 12110066, 5111612, 12109824, 5479082, 12233890, 64, 15447990, 5547587} i = <optimized out> prev_modiff = 123690 prev_buffer = 0x2a01880 #16 0x0000000000549d6e in internal_condition_case (bfun=bfun <at> entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun <at> entry=0x4dfe30 <cmd_error>) at eval.c:1345 val = <optimized out> c = <optimized out> #17 0x00000000004db4de in command_loop_2 (ignore=ignore <at> entry=12110066) at keyboard.c:1170 val = 0 #18 0x0000000000549c7b in internal_catch (tag=12157474, func=func <at> entry=0x4db4c0 <command_loop_2>, arg=12110066) at eval.c:1109 val = <optimized out> c = <optimized out> #19 0x00000000004dfa57 in command_loop () at keyboard.c:1149 No locals. #20 recursive_edit_1 () at keyboard.c:777 val = 20085232 #21 0x00000000004dfd42 in Frecursive_edit () at keyboard.c:841 buffer = 12110066 #22 0x0000000000413c55 in main (argc=<optimized out>, argv=0x7fff19cc4bc8) at emacs.c:1643 dummy = 140147689943936 stack_bottom_variable = -1 '\377' do_initial_setlocale = <optimized out> dumping = <optimized out> skip_args = 1 ---Type <return> to continue, or q <return> to quit--- rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615} no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x7f76ad467018 "\340\346%\255v\177" original_pwd = <optimized out> (gdb)
[Message part 3 (text/plain, inline)]
In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-02-02 on holos Configured using: `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro' 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: 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 transient-mark-mode: t Load-path shadows: /usr/share/emacs/site-lisp/timeclock hides /usr/share/emacs/24.3.50/lisp/calendar/timeclock Features: (shadow emacsbug sendmail vc-git nnir flow-fill shr browse-url misearch multi-isearch qp mm-archive mule-util sort ansi-color gnus-cite mail-extr gnus-async gnus-bcklg gnus-ml disp-table nndraft nnmh utf-7 nnimap utf7 nnfolder parse-time netrc gnutls network-stream auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core starttls tls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime password-cache dig mailcap nntp gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range message idna format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader gnus-util mail-utils mm-util mail-prsvr wid-edit xterm advice help-fns windmove edmacro kmacro cl-loaddefs cl-lib time-date paren zenburn-theme saveplace 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)
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Fri, 07 Feb 2014 07:17:01 GMT) Full text and rfc822 format available.Message #8 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Fri, 07 Feb 2014 09:16:29 +0200
> From: Mark Oteiza <mvoteiza <at> udel.edu> > Date: Thu, 06 Feb 2014 16:25:07 -0500 > > I have had several similar crashes over the past couple weeks, using the > daemon and a variety of clients in and out of tmux sessions. I attached > the backtrace the most recent crash. > Program terminated with signal 6, Aborted. > #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 > (gdb) bt > #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 > #1 0x00000000004db076 in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378 > #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127 > #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120 This is here: void cmcheckmagic (struct tty_display_info *tty) { if (curX (tty) == FrameCols (tty)) { if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1) emacs_abort (); <<<<<<<<<<<<<<<<<<<<<<<< Can you find out which of the two conditions triggered the abort? Also, what are "client-daemon" and "tmux", and how are they related to Emacs? Finally, can you try reproducing this in an unoptimized build? I'm afraid optimized builds lie to GDB about the exact point of crash and about backtrace that led to the crash. Thanks.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Fri, 07 Feb 2014 16:06:02 GMT) Full text and rfc822 format available.Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Fri, 07 Feb 2014 11:06:40 -0500
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Mark Oteiza <mvoteiza <at> udel.edu> >> Date: Thu, 06 Feb 2014 16:25:07 -0500 >> >> I have had several similar crashes over the past couple weeks, using the >> daemon and a variety of clients in and out of tmux sessions. I attached >> the backtrace the most recent crash. >> Program terminated with signal 6, Aborted. >> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 >> (gdb) bt >> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0 >> #1 0x00000000004db076 in terminate_due_to_signal (sig=sig <at> entry=6, >> backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378 >> #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127 >> #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120 > > This is here: > > void > cmcheckmagic (struct tty_display_info *tty) > { > if (curX (tty) == FrameCols (tty)) > { > if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1) > emacs_abort (); <<<<<<<<<<<<<<<<<<<<<<<< > > Can you find out which of the two conditions triggered the abort? Neither xterm-termite (the terminal emulator's info) nor screen-256color (the terminfo used inside tmux) have xn. Because of *how* I managed to reproduce the crash, I guess it is the second condition. > 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. This does not happen in 24.3, so this is a regression I imagine I can bisect if need be. 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. I seemed to need to have a file open in one of the clients. > Finally, can you try reproducing this in an unoptimized build? I'm > afraid optimized builds lie to GDB about the exact point of crash and > about backtrace that led to the crash. > > Thanks. I hope this output is more helpful. 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 --param=ssp-buffer-size=4 -g -fvar-tracking-assignments' CPPFLAGS= LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro'
[emacs_btfull_07feb.txt (text/plain, inline)]
Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50 Fri 2014-02-07 10:01:48 EST 13555 1000 100 6 /usr/bin/emacs-24.3.50 [master* ~]$ sudo systemd-coredumpctl gdb 13555 TIME PID UID GID SIG EXE Fri 2014-02-07 10:01:48 EST 13555 1000 100 6 /usr/bin/emacs-24.3.50 GNU gdb (GDB) 7.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/emacs-24.3.50...done. warning: core file may not match specified executable file. [New LWP 13555] [New LWP 13556] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffa4dfe000 Core was generated by `emacs --daemon'. Program terminated with signal 6, Aborted. #0 0x00007fa61950374b in raise () from /usr/lib/libpthread.so.0 (gdb) bt full #0 0x00007fa61950374b in raise () from /usr/lib/libpthread.so.0 No symbol table info available. #1 0x0000000000536755 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:378 No locals. #2 0x00000000005599ad in emacs_abort () at sysdep.c:2127 No locals. #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 #7 0x000000000041b6e6 in update_frame_1 (f=0x1251078, force_p=true, inhibit_id_p=false) at dispnew.c:4461 current_matrix = 0xcef6f0 desired_matrix = 0x143c2f0 i = 0 pause_p = false preempt_count = 17 #8 0x000000000041850c in update_frame (f=0x1251078, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3073 paused_p = false root_window = 0x138e158 #9 0x000000000044fe61 in redisplay_internal () at xdisp.c:13670 gcscrollbars = true f = 0x1251078 w = 0x1198c28 ---Type <return> to continue, or q <return> to quit--- sw = 0x1198c28 fr = 0x1251078 pending = 0 must_finish = true match_p = true tlbufpos = {charpos = 192, bytepos = 192} tlendpos = {charpos = 0, bytepos = 0} number_of_visible_frames = 3 count = 2 sf = 0x1251078 polling_stopped_here = 1 tail = 21163478 frame = 19206269 consider_all_windows_p = true update_miniwindow_p = true #10 0x0000000000449006 in resize_echo_area_exactly () at xdisp.c:10554 w = 0xc53a98 resize_exactly = 12843298 resized_p = 1 #11 0x000000000053b19c in command_loop_1 () at keyboard.c:1571 cmd = 12885778 keybuf = {27821702, 12, 0, 0, 4, 12980578, 12890706, 27848854, 9356513, 12980578, 140735958462224, 5481800, 140735958462272, 27848854, 140735958462224, 0, 140735958462352, 5481560, 140735958462304, 27848854, 12843250, 12843250, 12967168, 12843250, 0, 0, 140735958462352, 6083840, 12843250, 8556586760117233664} i = 1 prev_modiff = 22 prev_buffer = 0xc461b0 already_adjusted = false #12 0x00000000005cc00a in internal_condition_case (bfun=0x53aa04 <command_loop_1>, handlers=12894818, hfun=0x53a2f3 <cmd_error>) at eval.c:1352 val = 21700624 c = 0x14b2010 #13 0x000000000053a75e in command_loop_2 (ignore=12843250) at keyboard.c:1170 val = 0 #14 0x00000000005cb81c in internal_catch (tag=12890754, func=0x53a738 <command_loop_2>, arg=12843250) at eval.c:1116 val = 12843250 c = 0x14b1ee0 #15 0x000000000053a70c in command_loop () at keyboard.c:1149 No locals. #16 0x0000000000539eee in recursive_edit_1 () at keyboard.c:777 count = 1 val = 5480563 #17 0x000000000053a05b in Frecursive_edit () at keyboard.c:841 count = 0 buffer = 12843250 #18 0x0000000000538063 in main (argc=2, argv=0x7fffa4cfb298) at emacs.c:1643 dummy = 140351468168328 stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 1 rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615} ---Type <return> to continue, or q <return> to quit--- no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0xf63d4e2e <Address 0xf63d4e2e out of bounds> original_pwd = 0x0 (gdb)
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sat, 08 Feb 2014 10:43:01 GMT) Full text and rfc822 format available.Message #14 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sat, 08 Feb 2014 12:41:55 +0200
> From: Mark Oteiza <mvoteiza <at> 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?
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 09 Feb 2014 07:38:04 GMT) Full text and rfc822 format available.Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: 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.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 09 Feb 2014 17:28:02 GMT) Full text and rfc822 format available.Message #20 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu>, Dmitry Antipov <dmantipov <at> yandex.ru> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 09 Feb 2014 19:27:08 +0200
> From: Mark Oteiza <mvoteiza <at> udel.edu> > 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. Not sure what Emacs can do under these conditions. However, it worked before this change: > >> 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). Dmitry, this is bzr revision 113891. Perhaps the new code in delete_frame should include a few more tests from candidate_frame? (That's just a wild guess, though: I don't really understand what does tmux do to Emacs -- are we selecting a frame that is no longer displayed or something?)
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Wed, 09 Apr 2014 19:32:02 GMT) Full text and rfc822 format available.Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Wed, 09 Apr 2014 15:30:37 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: >> >> 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). > > Dmitry, this is bzr revision 113891. Perhaps the new code in > delete_frame should include a few more tests from candidate_frame? > (That's just a wild guess, though: I don't really understand what does > tmux do to Emacs -- are we selecting a frame that is no longer > displayed or something?) I looked at Bug#15025 and figured the recipe here can be simpler: 1. emacs --daemon -Q 2. open two xterms 3. do `emacsclient -t` in both 4. exit one emacsclient The remaining emacsclient has no focus. Resizing the xterm has no effect on the client. Out of curiosity, I tried reverting r113891 (g0cd28af). As expected, I could reproduce Bug#15025. I still have not found a recipe for reproducing the crash. Is there any debugging I can do to help the issue?
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sat, 26 Jul 2014 16:24:02 GMT) Full text and rfc822 format available.Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sat, 26 Jul 2014 12:23:12 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Mark Oteiza <mvoteiza <at> udel.edu> >> Date: Sun, 09 Feb 2014 02:39:09 -0500 >> >> I found 0cd28af (references Bug#15025). > > Dmitry, this is bzr revision 113891. Perhaps the new code in > delete_frame should include a few more tests from candidate_frame? > (That's just a wild guess, though: I don't really understand what does > tmux do to Emacs -- are we selecting a frame that is no longer > displayed or something?) New recipe for crash (guided by Eli's comment on #18112): Open a terminal emulator (TE) window. In that window: emacs --daemon -Q emacsclient -t C-x 2 In another TE window, emacsclient -t C-x C-c Go back to the first TE. Widen it, and shorten it so that the top buffer is no longer visible. Send input -- now emacs should have crashed. For the record, here is the original recipe I had found for the crash: 1. emacs --daemon -Q 2. Split vertically the tmux window into two panes: <prefix> % 3. Start a client in one of the tmux panes: emacsclient -t 4. C-x 2 5. Break out the tmux pane containing the client to a new window: <prefix>-! 6. Split vertically the tmux window into two panes: <prefix> % 7. Open a new client. 8. Exit the new client. 9. Close the new tmux pane (^D). Now the first client occupies half the tmux window and is unfocused 10. Shrink the terminal emulator. Things should look bad now. 11. Send input to the client.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sat, 26 Jul 2014 16:32:02 GMT) Full text and rfc822 format available.Message #29 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sat, 26 Jul 2014 19:31:42 +0300
> From: Mark Oteiza <mvoteiza <at> udel.edu> > Date: Sat, 26 Jul 2014 12:23:12 -0400 > > Open a terminal emulator (TE) window. In that window: > > emacs --daemon -Q > emacsclient -t > C-x 2 > > In another TE window, > > emacsclient -t > C-x C-c > > Go back to the first TE. Widen it, and shorten it so that the top > buffer is no longer visible. Send input -- now emacs should have crashed. This sounds very much as a duplicate of #18112, the only difference being that the terminal window is being resized horizontally, not vertically.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 27 Jul 2014 13:08:01 GMT) Full text and rfc822 format available.Message #32 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: mvoteiza <at> udel.edu Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 27 Jul 2014 16:07:55 +0300
> Date: Sat, 26 Jul 2014 19:31:42 +0300 > From: Eli Zaretskii <eliz <at> gnu.org> > Cc: 16674 <at> debbugs.gnu.org > > > From: Mark Oteiza <mvoteiza <at> udel.edu> > > Date: Sat, 26 Jul 2014 12:23:12 -0400 > > > > Open a terminal emulator (TE) window. In that window: > > > > emacs --daemon -Q > > emacsclient -t > > C-x 2 > > > > In another TE window, > > > > emacsclient -t > > C-x C-c > > > > Go back to the first TE. Widen it, and shorten it so that the top > > buffer is no longer visible. Send input -- now emacs should have crashed. > > This sounds very much as a duplicate of #18112, the only difference > being that the terminal window is being resized horizontally, not > vertically. I think revision 117409 on the emacs-24 branch fixes this one as well. At least I no longer can reproduce the bug both with your original and the simplified recipes. Please check.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 27 Jul 2014 15:25:02 GMT) Full text and rfc822 format available.Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 27 Jul 2014 11:24:11 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: >> Date: Sat, 26 Jul 2014 19:31:42 +0300 >> From: Eli Zaretskii <eliz <at> gnu.org> >> Cc: 16674 <at> debbugs.gnu.org >> >> > From: Mark Oteiza <mvoteiza <at> udel.edu> >> > Date: Sat, 26 Jul 2014 12:23:12 -0400 >> > >> > Open a terminal emulator (TE) window. In that window: >> > >> > emacs --daemon -Q >> > emacsclient -t >> > C-x 2 >> > >> > In another TE window, >> > >> > emacsclient -t >> > C-x C-c >> > >> > Go back to the first TE. Widen it, and shorten it so that the top >> > buffer is no longer visible. Send input -- now emacs should have crashed. >> >> This sounds very much as a duplicate of #18112, the only difference >> being that the terminal window is being resized horizontally, not >> vertically. Yes, definitely. Before your fix, reverting 0cd28af (bzr 113891) made both recipes harmless. > I think revision 117409 on the emacs-24 branch fixes this one as well. > At least I no longer can reproduce the bug both with your original and > the simplified recipes. Please check. Yes, this appears to be fixed in the emacs-24 branch, thank you!!! Let me add that I also tested your fix on emacs-24 with bzr 113891 reverted on top of it. I could not reproduce #15025, #16674, or #18112 in this case. As the #15025 fix leads to unfocused and ultimately very broken-looking frames, please consider reverting that change.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 27 Jul 2014 16:25:02 GMT) Full text and rfc822 format available.Message #38 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 27 Jul 2014 19:24:38 +0300
> From: Mark Oteiza <mvoteiza <at> udel.edu> > Date: Sun, 27 Jul 2014 11:24:11 -0400 > > Let me add that I also tested your fix on emacs-24 with bzr 113891 > reverted on top of it. I could not reproduce #15025, #16674, or #18112 > in this case. As the #15025 fix leads to unfocused and ultimately very > broken-looking frames, please consider reverting that change. Sorry, I don't understand: what are the problems caused by 113891? what do you mean by "unfocused and broken-looking frames"?
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 27 Jul 2014 17:39:02 GMT) Full text and rfc822 format available.Message #41 received at 16674 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674 <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 27 Jul 2014 20:39:04 +0300
> From: Mark Oteiza <mvoteiza <at> udel.edu> > Date: Sun, 27 Jul 2014 12:51:15 -0400 > > With 113891 reverted, a visible frame is always found and selected if > one closes a client frame, also all the visible clients will always > respond to resizes. But what about the original recipes described in #15025? The change I made to solve #18112 cannot possibly fix it, because all it does is fix the calculation of the _dimensions_ of the frame being resized. So reverting 113891 is almost certainly going to reintroduce #15025.
bug-gnu-emacs <at> gnu.org
:bug#16674
; Package emacs
.
(Sun, 27 Jul 2014 17:51:01 GMT) Full text and rfc822 format available.Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mark Oteiza <mvoteiza <at> udel.edu> To: bug-gnu-emacs <at> gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Sun, 27 Jul 2014 13:50:31 -0400
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Mark Oteiza <mvoteiza <at> udel.edu> >> Date: Sun, 27 Jul 2014 12:51:15 -0400 >> >> With 113891 reverted, a visible frame is always found and selected if >> one closes a client frame, also all the visible clients will always >> respond to resizes. > > But what about the original recipes described in #15025? The change I > made to solve #18112 cannot possibly fix it, because all it does is > fix the calculation of the _dimensions_ of the frame being resized. > So reverting 113891 is almost certainly going to reintroduce #15025. My mistake. I had tried this recipe <https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00282.html> but I must have erred somehow.
Eli Zaretskii <eliz <at> gnu.org>
:Mark Oteiza <mvoteiza <at> udel.edu>
:Message #49 received at 16674-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Mark Oteiza <mvoteiza <at> udel.edu> Cc: 16674-done <at> debbugs.gnu.org Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Date: Mon, 28 Jul 2014 09:34:20 +0300
> From: Mark Oteiza <mvoteiza <at> udel.edu> > Date: Sun, 27 Jul 2014 13:50:31 -0400 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> From: Mark Oteiza <mvoteiza <at> udel.edu> > >> Date: Sun, 27 Jul 2014 12:51:15 -0400 > >> > >> With 113891 reverted, a visible frame is always found and selected if > >> one closes a client frame, also all the visible clients will always > >> respond to resizes. > > > > But what about the original recipes described in #15025? The change I > > made to solve #18112 cannot possibly fix it, because all it does is > > fix the calculation of the _dimensions_ of the frame being resized. > > So reverting 113891 is almost certainly going to reintroduce #15025. > > My mistake. I had tried this recipe > <https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00282.html> > but I must have erred somehow. OK, I will close this bug. Feel free to file a separate bug report about what happens when a client frame is closed on another TTY.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Mon, 25 Aug 2014 11:24:03 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.