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

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

[Mark Oteiza]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]


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


[-- Attachment #2: daemon crash bt full --]
[-- Type: text/plain, Size: 12691 bytes --]

              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@entry=6, backtrace_limit=backtrace_limit@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@entry=0x12996e8, vpos=50) at dispnew.c:4791
#5  0x000000000041af74 in update_frame_1 (f=f@entry=0x12996e8, force_p=force_p@entry=true, inhibit_id_p=inhibit_id_p@entry=false) at dispnew.c:4461
#6  0x000000000041caeb in update_frame (f=f@entry=0x12996e8, force_p=<optimized out>, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@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@entry=11) at xdisp.c:13879
#9  0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true,
    wait_for_cell=wait_for_cell@entry=12110066, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@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@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7fff19cc4510, prev_event=prev_event@entry=12110066,
    used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b) at keyboard.c:2302
#13 0x00000000004e66af in read_char (commandflag=1, map=map@entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b,
    end_time=end_time@entry=0x0) at keyboard.c:2888
#14 0x00000000004e7463 in read_key_sequence (keybuf=keybuf@entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@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@entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4dfe30 <cmd_error>) at eval.c:1345
#17 0x00000000004db4de in command_loop_2 (ignore=ignore@entry=12110066) at keyboard.c:1170
#18 0x0000000000549c7b in internal_catch (tag=12157474, func=func@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@entry=6, backtrace_limit=backtrace_limit@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@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@entry=0x12996e8, force_p=force_p@entry=true, inhibit_id_p=inhibit_id_p@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@entry=0x12996e8, force_p=<optimized out>, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@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@entry=11) at xdisp.c:13879
No locals.
#9  0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true,
    wait_for_cell=wait_for_cell@entry=12110066, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@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@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7fff19cc4510, prev_event=prev_event@entry=12110066,
    used_mouse_menu=used_mouse_menu@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@entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b,
    end_time=end_time@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@entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@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@entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4dfe30 <cmd_error>) at eval.c:1345
        val = <optimized out>
        c = <optimized out>
#17 0x00000000004db4de in command_loop_2 (ignore=ignore@entry=12110066) at keyboard.c:1170
        val = 0
#18 0x0000000000549c7b in internal_catch (tag=12157474, func=func@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)

[-- Attachment #3: Type: text/plain, Size: 2832 bytes --]





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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@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@entry=6, backtrace_limit=backtrace_limit@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Mark Oteiza]

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark Oteiza <mvoteiza@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@entry=6,
>> backtrace_limit=backtrace_limit@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'


[-- Attachment #2: emacs bt full --]
[-- Type: text/plain, Size: 5799 bytes --]

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

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

[Mark Oteiza]

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

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sun, 09 Feb 2014 02:39:09 -0500
> 
> 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.

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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Mark Oteiza]

Eli Zaretskii <eliz@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> Date: Sat, 26 Jul 2014 19:31:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16674@debbugs.gnu.org
> 
> > From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 26 Jul 2014 19:31:42 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 16674@debbugs.gnu.org
>> 
>> > From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@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#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark Oteiza <mvoteiza@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.

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

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sun, 27 Jul 2014 13:50:31 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Mark Oteiza <mvoteiza@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.