GNU bug report logs - #17691
24.3.91; crash closing remote frame

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17691 in the body.
You can then email your comments to 17691 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; crash closing remote frame
Date: Wed, 04 Jun 2014 13:09:03 -0400

1) Build Emacs with "lucid" toolkit because you like making frames on
   multiple displays.
2) Fire up Emacs on your local X11 display :0.
3) ssh into the machine and use emacsclient to get a frame on display
   :10 or whatever.
4) Drop the remote connection, or use your window manager to kill the
   remote frame, or poke around in (current-frame-configuration) to find
   the frame and apply delete-frame to it.
5) Watch your Emacs process die.

It seems to be repeatable.




Program received signal SIGSEGV, Segmentation fault.
PSEUDOVECTORP (code=15, a=122485729734501) at lisp.h:2394
2394	      return PSEUDOVECTOR_TYPEP (h, code);
(gdb) bt
#0  PSEUDOVECTORP (code=15, a=122485729734501) at lisp.h:2394
#1  font_clear_cache (cache=69278262, driver=<optimized out>, f=<optimized out>) at font.c:2604
#2  0x0000000000564f0b in font_finish_cache (driver=0xb707a0, f=0x45a77b0) at font.c:2563
#3  font_update_drivers (f=0x45a77b0, new_drivers=12059762) at font.c:3472
#4  0x000000000041effc in delete_frame (frame=<optimized out>, force=12059810) at frame.c:1335
#5  0x0000000000551580 in Ffuncall (nargs=<optimized out>, args=0x7fffa40cdcb8) at eval.c:2818
#6  0x000000000058664d in exec_byte_code (bytestr=4611686018679046144, vector=11995040, maxdepth=4611686019484352512, args_template=54, nargs=3, args=0x0) at bytecode.c:916
#7  0x000000000055103f in funcall_lambda (fun=9785413, nargs=<optimized out>, arg_vector=0x7fffa40cdeb8) at eval.c:3049
#8  0x0000000000551364 in Ffuncall (nargs=<optimized out>, args=0x7fffa40cdeb0) at eval.c:2876
#9  0x000000000054d885 in Fcall_interactively (function=12419650, record_flag=12059762, keys=40388517) at callint.c:836
#10 0x000000000055156d in Ffuncall (nargs=<optimized out>, args=0x7fffa40ce088) at eval.c:2822
#11 0x000000000058664d in exec_byte_code (bytestr=4611686018679046144, vector=11995040, maxdepth=4611686019484352512, args_template=108, nargs=4, args=0x7fffa40ce1d8) at bytecode.c:916
#12 0x0000000000551364 in Ffuncall (nargs=<optimized out>, args=0x7fffa40ce1d0) at eval.c:2876
#13 0x0000000000551759 in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>) at eval.c:2663
#14 0x00000000004e8dee in read_char (commandflag=1, map=60420038, prev_event=12059762, used_mouse_menu=0x7fffa40ce5bf, end_time=0x0) at keyboard.c:2944
#15 0x00000000004ea9e4 in read_key_sequence (keybuf=0x7fffa40ce610, prompt=12059762, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, bufsize=30) at keyboard.c:9087
#16 0x00000000004ebc1a in command_loop_1 () at keyboard.c:1452
#17 0x000000000054f942 in internal_condition_case (bfun=0x4eba40 <command_loop_1>, handlers=<optimized out>, hfun=0x4e2ce0 <cmd_error>) at eval.c:1354
#18 0x00000000004e057e in command_loop_2 (ignore=<optimized out>) at keyboard.c:1177
#19 0x000000000054f848 in internal_catch (tag=<error reading variable: Cannot access memory at address 0x400000000effffc8>, func=0x4e0560 <command_loop_2>, arg=12059762) at eval.c:1118
#20 0x00000000004e28c7 in command_loop () at keyboard.c:1156
#21 recursive_edit_1 () at keyboard.c:777
#22 0x00000000004e2bed in Frecursive_edit () at keyboard.c:848
#23 0x0000000000411775 in main (argc=2, argv=<optimized out>) at emacs.c:1646

Lisp Backtrace:
"delete-frame" (0xa40cdcc0)
"handle-delete-frame" (0xa40cdeb8)
"call-interactively" (0xa40ce090)
"command-execute" (0xa40ce1d8)
(gdb) fr 1
#1  PSEUDOVECTORP (code=15, a=122485729734501) at lisp.h:2394
2394	      return PSEUDOVECTOR_TYPEP (h, code);
(gdb) list
2389	    return false;
2390	  else
2391	    {
2392	      /* Converting to struct vectorlike_header * avoids aliasing issues.  */
2393	      struct vectorlike_header *h = XUNTAG (a, Lisp_Vectorlike);
2394	      return PSEUDOVECTOR_TYPEP (h, code);
2395	    }
2396	}
2397	
2398	
(gdb) p a
$1 = 122485729734501
(gdb) xtype 
Lisp_Vectorlike
Cannot access memory at address 0x6f666e692f60
(gdb) p/x a
$2 = 0x6f666e692f65

Note that this is an invalid pointer but valid ASCII string content
("e/info\0\0" after byte swapping).

I told gdb to save a core file (it reported errors accessing some
memory) and went back to look at the core file when I had a useable
emacs process running again. (Poor foresight on my part, "xbacktrace"
doesn't work on a core file.)



(gdb) bt full 
#0  PSEUDOVECTOR_TYPEP (code=15, a=<optimized out>) at lisp.h:2380
No locals.
#1  PSEUDOVECTORP (code=15, a=122485729734501) at lisp.h:2394
        h = 0x4212a90
#2  font_clear_cache (cache=69278262, driver=<optimized out>, f=<optimized out>) at font.c:2604
        tail = 69282438
        entity = 122485729734501
        i = <optimized out>
#3  0x0000000000564f0b in font_finish_cache (driver=0xb707a0, f=0x45a77b0) at font.c:2563
        cache = <optimized out>
        val = <optimized out>
#4  font_update_drivers (f=0x45a77b0, new_drivers=12059762) at font.c:3472
        driver = 0xb707a0
        active_drivers = 12059762
        list = 0x27b2020
#5  0x000000000041effc in delete_frame (frame=<optimized out>, force=12059810) at frame.c:1335
        f = 0x45a77b0
        sf = <optimized out>
        kb = <optimized out>
        minibuffer_selected = 0
        is_tooltip_frame = 0
#6  0x0000000000551580 in Ffuncall (nargs=<optimized out>, args=0x7fffa40cdcb8) at eval.c:2818
        fun = 8580261
        original_fun = <optimized out>
        funcar = 4611686018679046144
        numargs = <optimized out>
        val = <optimized out>
        internal_args = 0x7fffa40cdcc0
        i = <optimized out>
#7  0x000000000058664d in exec_byte_code (bytestr=4611686018679046144, vector=11995040, maxdepth=4611686019484352512, args_template=54, nargs=3, args=0x0) at bytecode.c:916
        targets = {0x5866e1, 0x586f0b, 0x586f10, 0x586f15, 0x5864c2, 0x5864c8, 0x588019, 0x588062, 0x5880ea, 0x5880ef, 0x5880bb, 0x5880c0, 0x586505, 0x586508, 0x586bb0, 0x5880c5, 0x586d3b, 0x586d40, 0x586dc1, 0x586dc6, 0x586574, 0x586578, 0x586d6a, 0x586d45, 0x586df0, 0x586df5, 0x586dfa, 0x586e05, 0x5865e9, 0x5865f0, 0x586dad, 0x586dcb, 0x586e4e, 0x586e53, 0x586e58, 0x586e65, 0x58662f, 0x586630, 0x586e15, 0x586e29, 0x586751, 0x586756, 0x58675b, 0x586e89, 0x586670, 0x586670, 0x586e75, 0x58672c, 0x5883c8, 0x5883bd, 0x58828a, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x587e4f, 0x587eeb, 0x587f26, 0x587f61, 0x587f9c, 0x586c7b, 0x586cbd, 0x587fe4, 0x586c3d, 0x586cfd, 0x5889b2, 0x588874, 0x5888a3, 0x588af5, 0x588b32, 0x588a42, 0x588a71, 0x588ab1, 0x58854f, 0x58857e, 0x5885ad, 0x5885ed, 0x58862d, 0x58866d, 0x5886b1, 0x5886ee, 0x58872b, 0x5887b8, 0x5887f8, 0x588834, 0x58896d, 0x5888e3, 0x588928, 0x5874a2, 0x5874e7, 0x587524, 0x587559, 0x587596, 0x5875d3, 0x587610, 0x5876ca, 0x5866b3, 0x587708, 0x587737, 0x5877b8, 0x5877f6, 0x587834, 0x587863, 0x587898, 0x5878c9, 0x5878fe, 0x5866e1, 0x587934, 0x587969, 0x58799e, 0x5879d3, 0x587a08, 0x587a3d, 0x5866b3, 0x5866e1, 0x587a6c, 0x587ab3, 0x587ae2, 0x587b11, 0x587b51, 0x587b91, 0x58710f, 0x5871e2, 0x587d6e, 0x587dae, 0x587222, 0x587257, 0x5866e1, 0x5884fb, 0x586765, 0x586bc4, 0x5869e5, 0x586872, 0x586b03, 0x58744d, 0x5884da, 0x586d7e, 0x58738a, 0x587325, 0x588217, 0x588245, 0x5883f6, 0x588447, 0x58848b, 0x587dee, 0x5872f9, 0x587286, 0x5872ca, 0x587bc0, 0x587bef, 0x587c1e, 0x587c4d, 0x587c8d, 0x587ccd, 0x587d0d, 0x587d4d, 0x586f25, 0x586f65, 0x586fa5, 0x586fd4, 0x587014, 0x587054, 0x587093, 0x5870d2, 0x58764d, 0x58768a, 0x586e8e, 0x586ed5, 0x5866e1, 0x5867f5, 0x586a99, 0x5868e5, 0x58697f, 0x5873b8, 0x5889f2, 0x588768, 0x587768, 0x5880f4, 0x588139, 0x5866e1, 0x5866e1, 0x588191, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5881dc <repeats 64 times>}
        count = 8
        stack = {
          pc = 0xa7b994 "\202\070", 
          byte_string = 9785465, 
          byte_string_start = 0xa7b961 "\304\b!\211@\262\001\305\306 \031\032\033\t\203)", 
          next = 0x7fffa40ce0f0
        }
        result = 4611686018679046144
        type = CATCHER
#8  0x000000000055103f in funcall_lambda (fun=9785413, nargs=<optimized out>, arg_vector=0x7fffa40cdeb8) at eval.c:3049
        val = <optimized out>
        syms_left = 12059762
        next = 12059762
        lexenv = 12059762
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
#9  0x0000000000551364 in Ffuncall (nargs=<optimized out>, args=0x7fffa40cdeb0) at eval.c:2876
        fun = <optimized out>
        original_fun = 12419650
        funcar = 4611686018679046144
        numargs = <optimized out>
        val = <optimized out>
        internal_args = <optimized out>
        i = <optimized out>
#10 0x000000000054d885 in Fcall_interactively (function=12419650, record_flag=12059762, keys=40388517) at callint.c:836
        val = <optimized out>
        args = 0x7fffa40cdeb0
        visargs = 0x7fffa40cde90
        specs = <optimized out>
        filter_specs = <optimized out>
        teml = <optimized out>
        up_event = 12059762
        enable = 140735945694832
        next_event = <optimized out>
        prefix_arg = 12059762
        string = <optimized out>
        tem = <optimized out>
        varies = 0x7fffa40cde70 ""
        i = <optimized out>
        nargs = <optimized out>
        mark = <optimized out>
        arg_from_tty = <optimized out>
        key_count = 1
        record_then_fail = false
        save_this_command = 12059762
        save_last_command = 12102322
        save_this_original_command = 12059762
        save_real_this_command = 12059762
#11 0x000000000055156d in Ffuncall (nargs=<optimized out>, args=0x7fffa40ce088) at eval.c:2822
        fun = 11474597
        original_fun = <optimized out>
        funcar = 4611686018679046144
        numargs = <optimized out>
        val = <optimized out>
        internal_args = 0x7fffa40ce090
        i = <optimized out>
#12 0x000000000058664d in exec_byte_code (bytestr=4611686018679046144, vector=11995040, maxdepth=4611686019484352512, args_template=108, nargs=4, args=0x7fffa40ce1d8) at bytecode.c:916
        targets = {0x5866e1, 0x586f0b, 0x586f10, 0x586f15, 0x5864c2, 0x5864c8, 0x588019, 0x588062, 0x5880ea, 0x5880ef, 0x5880bb, 0x5880c0, 0x586505, 0x586508, 0x586bb0, 0x5880c5, 0x586d3b, 0x586d40, 0x586dc1, 0x586dc6, 0x586574, 0x586578, 0x586d6a, 0x586d45, 0x586df0, 0x586df5, 0x586dfa, 0x586e05, 0x5865e9, 0x5865f0, 0x586dad, 0x586dcb, 0x586e4e, 0x586e53, 0x586e58, 0x586e65, 0x58662f, 0x586630, 0x586e15, 0x586e29, 0x586751, 0x586756, 0x58675b, 0x586e89, 0x586670, 0x586670, 0x586e75, 0x58672c, 0x5883c8, 0x5883bd, 0x58828a, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x587e4f, 0x587eeb, 0x587f26, 0x587f61, 0x587f9c, 0x586c7b, 0x586cbd, 0x587fe4, 0x586c3d, 0x586cfd, 0x5889b2, 0x588874, 0x5888a3, 0x588af5, 0x588b32, 0x588a42, 0x588a71, 0x588ab1, 0x58854f, 0x58857e, 0x5885ad, 0x5885ed, 0x58862d, 0x58866d, 0x5886b1, 0x5886ee, 0x58872b, 0x5887b8, 0x5887f8, 0x588834, 0x58896d, 0x5888e3, 0x588928, 0x5874a2, 0x5874e7, 0x587524, 0x587559, 0x587596, 0x5875d3, 0x587610, 0x5876ca, 0x5866b3, 0x587708, 0x587737, 0x5877b8, 0x5877f6, 0x587834, 0x587863, 0x587898, 0x5878c9, 0x5878fe, 0x5866e1, 0x587934, 0x587969, 0x58799e, 0x5879d3, 0x587a08, 0x587a3d, 0x5866b3, 0x5866e1, 0x587a6c, 0x587ab3, 0x587ae2, 0x587b11, 0x587b51, 0x587b91, 0x58710f, 0x5871e2, 0x587d6e, 0x587dae, 0x587222, 0x587257, 0x5866e1, 0x5884fb, 0x586765, 0x586bc4, 0x5869e5, 0x586872, 0x586b03, 0x58744d, 0x5884da, 0x586d7e, 0x58738a, 0x587325, 0x588217, 0x588245, 0x5883f6, 0x588447, 0x58848b, 0x587dee, 0x5872f9, 0x587286, 0x5872ca, 0x587bc0, 0x587bef, 0x587c1e, 0x587c4d, 0x587c8d, 0x587ccd, 0x587d0d, 0x587d4d, 0x586f25, 0x586f65, 0x586fa5, 0x586fd4, 0x587014, 0x587054, 0x587093, 0x5870d2, 0x58764d, 0x58768a, 0x586e8e, 0x586ed5, 0x5866e1, 0x5867f5, 0x586a99, 0x5868e5, 0x58697f, 0x5873b8, 0x5889f2, 0x588768, 0x587768, 0x5880f4, 0x588139, 0x5866e1, 0x5866e1, 0x588191, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5866e1, 0x5881dc <repeats 64 times>}
        count = 3
        stack = {
          pc = 0xa9b4fa "\006\006\071\203\233", 
          byte_string = 9530937, 
          byte_string_start = 0xa9b486 "\306\020\211?\205\f", 
          next = 0x0
        }
        result = 4611686018679046144
        type = 2752307672
#13 0x0000000000551364 in Ffuncall (nargs=<optimized out>, args=0x7fffa40ce1d0) at eval.c:2876
        fun = <optimized out>
        original_fun = 12103650
        funcar = 4611686018679046144
        numargs = <optimized out>
        val = <optimized out>
        internal_args = <optimized out>
        i = <optimized out>
#14 0x0000000000551759 in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>) at eval.c:2663
        ret_ungc_val = 4611686018679046144
        args = {12103650, 12419650, 12059762, 40388517, 12059810}
#15 0x00000000004e8dee in read_char (commandflag=1, map=60420038, prev_event=12059762, used_mouse_menu=0x7fffa40ce5bf, end_time=0x0) at keyboard.c:2944
        prev_buffer = 0xb86d50
        c = 62612038
        local_getcjmp = {{
            __jmpbuf = {12059762, -3514578156732679419, 12059762, 62613222, 12059762, 0, 3514766505763142405, -3514570196288668923}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 11 times>, 12086608, 5537799, 20129915, 0, 0}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        tem = 12419650
        save = <optimized out>
        previous_echo_area_message = 12059762
        also_record = 12059762
        reread = false
        polling_stopped_here = false
        orig_kboard = 0x4322770
#16 0x00000000004ea9e4 in read_key_sequence (keybuf=0x7fffa40ce610, prompt=12059762, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, bufsize=30) at keyboard.c:9087
        interrupted_kboard = 0x4322770
        interrupted_frame = 0x45a6f08
        key = <optimized out>
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = <optimized out>
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = 60420038
        first_event = 12059762
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 69278518, 
          map = 69278518, 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = 12039750, 
          map = 12039750, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 69278534, 
          map = 69278534, 
          start = 0, 
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = 12059762
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0xb86d50
        fake_prefixed_keys = 12059762
#17 0x00000000004ebc1a in command_loop_1 () at keyboard.c:1452
        cmd = <optimized out>
        keybuf = {12107250, 5576045, 4294967296, 12059762, 0, 140735945696936, 3, 140735945696936, 16392194, -6727987734337709568, 4611686018595160064, 59337078, 12243042, 12059762, 4294967295, 140735945697696, 140735945697008, 5576580, 12107250, 59337078, 8613697, 12243042, 140735945697008, 5123245, 12107298, 59337078, 12059762, 5123575, 12059648, 16143360}
        i = <optimized out>
        prev_modiff = 0
        prev_buffer = 0x0
#18 0x000000000054f942 in internal_condition_case (bfun=0x4eba40 <command_loop_1>, handlers=<optimized out>, hfun=0x4e2ce0 <cmd_error>) at eval.c:1354
        val = <optimized out>
        c = 0x400000000effffc0
#19 0x00000000004e057e in command_loop_2 (ignore=<optimized out>) at keyboard.c:1177
        val = 4611686018679046144
#20 0x000000000054f848 in internal_catch (tag=<error reading variable: Cannot access memory at address 0x400000000effffc8>, func=0x4e0560 <command_loop_2>, arg=12059762) at eval.c:1118
        val = <optimized out>
        c = 0x400000000effffc0
#21 0x00000000004e28c7 in command_loop () at keyboard.c:1156
No locals.
#22 recursive_edit_1 () at keyboard.c:777
        val = 2
#23 0x00000000004e2bed in Frecursive_edit () at keyboard.c:848
        buffer = <optimized out>
#24 0x0000000000411775 in main (argc=2, argv=<optimized out>) at emacs.c:1646
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = <optimized out>
        dumping = <optimized out>
        skip_args = 1
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0xb80472 ""
You can't do that without a process to debug.
(gdb)

(gdb) fr 2
#2  font_clear_cache (cache=69278262, driver=<optimized out>, f=<optimized out>) at font.c:2604
2604		      if (FONT_ENTITY_P (entity)
(gdb) list
2599		  eassert (VECTORP (elt));
2600		  for (i = 0; i < ASIZE (elt); i++)
2601		    {
2602		      entity = AREF (elt, i);
2603	
2604		      if (FONT_ENTITY_P (entity)
2605			  && EQ (driver->type, AREF (entity, FONT_TYPE_INDEX)))
2606			{
2607			  Lisp_Object objlist = AREF (entity, FONT_OBJLIST_INDEX);
2608	
(gdb) p entity
$1 = 122485729734501
(gdb) p/x entity
$2 = 0x6f666e692f65
(gdb) p elt
$3 = <optimized out>
(gdb) p i 
$6 = <optimized out>
(gdb) 

I'm rebuilding with --enable-checking to look a little closer.


In GNU Emacs 24.3.91.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-05-29 on just-testing.permabit.com
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.4 LTS

Configured using:
 `configure
 --prefix=/permabit/user/raeburn/I64/install/emacs-24.3.91.precise
 --with-x-toolkit=lucid'

Important settings:
  locale-coding-system: nil

Major mode: Lisp Interaction

Minor modes in effect:
  rcirc-track-minor-mode: t
  display-time-mode: t
  which-function-mode: t
  icomplete-mode: t
  desktop-save-mode: t
  jabber-activity-mode: t
  eldoc-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <escape> x e m a c s - b u 
<tab> <escape> <backspace> <escape> <backspace> r e 
p o r t <tab> <return>

Recent messages:
Indentation variables are now local.
Indentation setup for shell type sh
Note: file is write protected [5 times]
Setting up indent for shell type bash
Indentation variables are now local.
Indentation setup for shell type bash
Wrote /permabit/user/raeburn/.emacs.d/.emacs.desktop.lock.just-testing.permabit.com
Desktop: 1 frame, 252 buffers restored.
Starting Emacs daemon.
When done with this frame, type C-x 5 0

Load-path shadows:
~/permabit-emacs/objdump hides /permabit/user/raeburn/elisp/objdump/objdump
~/permabit-emacs/kr-pdoc hides /permabit/user/raeburn/elisp/kr-pdoc
/permabit/user/raeburn/.emacs.d/elpa/systemtap-mode-20121209.1510/systemtap-mode hides /permabit/user/raeburn/elisp/systemtap-mode
/permabit/user/raeburn/.emacs.d/elpa/ssh-20120904.1342/ssh hides /permabit/user/raeburn/elisp/ssh
/permabit/user/raeburn/.emacs.d/elpa/edit-server-20131229.441/edit-server hides /permabit/user/raeburn/elisp/edit-server
~/permabit-emacs/c-fns hides /permabit/user/raeburn/elisp/c-fns
/permabit/user/raeburn/elisp/objdump/loaddefs hides /permabit/user/raeburn/I64/install/emacs-24.3.91.precise/share/emacs/24.3.91/lisp/loaddefs

Features:
(shadow sort mail-extr gnus-msg emacsbug sendmail mule-util make-mode
sh-script smie executable systemtap-mode cc-awk nroff-mode flyspell
ispell git-commit-mode server log-edit easy-mmode pcvs-util add-log
objdump autorevert filenotify rcirc vc-git hideshow cc-langs cc-mode
cc-fonts cc-guess cc-menus cc-cmds edit-server-autoloads info
git-rebase-mode-autoloads git-commit-mode-autoloads popup-autoloads
ssh-autoloads systemtap-mode-autoloads package time which-func warnings
imenu icomplete kr-stuff hideshowvis desktop frameset ses byte-opt
bytecomp byte-compile cconv unsafep browse-url edit-server gnus-demon
nntp gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime
password-cache dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
gnus-start gnus-spec gnus-int gnus-range message cl-macs rfc822 mml
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 iso-transl kr-dbus
notifications dbus kr-math jabber jabber-awesome jabber-osd jabber-wmii
jabber-xmessage jabber-festival jabber-sawfish jabber-ratpoison
jabber-screen jabber-socks5 jabber-ft-server jabber-si-server
jabber-ft-client jabber-ft-common jabber-si-client jabber-si-common
jabber-feature-neg jabber-truncate jabber-time jabber-autoaway
jabber-vcard-avatars jabber-chatstates jabber-events jabber-vcard
jabber-avatar mailcap jabber-activity jabber-watch jabber-modeline
jabber-ahc-presence jabber-ahc jabber-version jabber-ourversion
jabber-muc-nick-completion hippie-exp jabber-browse jabber-search
jabber-register jabber-roster format-spec jabber-presence time-date
assoc jabber-muc jabber-newdisco jabber-widget jabber-disco wid-edit
jabber-chat ewoc jabber-history jabber-chatbuffer jabber-alert jabber-iq
jabber-keymap jabber-core jabber-sasl sasl sasl-anonymous sasl-login
sasl-plain fsm jabber-logon jabber-conn srv dns starttls tls jabber-xml
xml jabber-menu jabber-util jabber-autoloads idutils derived thingatpt
compile comint ansi-color ring cperl-mode easymenu cc-styles cc-align
cc-engine cc-vars p4 dired kr-message-timestamp advice c-eldoc cl gv
cl-loaddefs cl-lib cc-defs eldoc help-fns timeclock 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)

Memory information:
((conses 16 595122 57649)
 (symbols 48 43738 0)
 (miscs 40 90119 5085)
 (strings 32 82057 9920)
 (string-bytes 1 2619894)
 (vectors 16 33642)
 (vector-slots 8 882063 10737)
 (floats 8 312 523)
 (intervals 56 23058 137)
 (buffers 960 266)
 (heap 1024 54013 1272))

Message #8 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: 17691 <at> debbugs.gnu.org
Subject: 24.3.91; crash closing remote frame
Date: Wed, 4 Jun 2014 13:34:23 -0400

The enable-checking build indicates that in the loop in font_clear_cache, an element of the list has a car slot with a font spec for "7x14" and a cdr slot of nil. If it matters, the remote display in this case is my Mac laptop, and it does appear to have a "7x14" font available to its X server.

Ken

Message #11 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: 17691 <at> debbugs.gnu.org
Subject: Re: 24.3.91; crash closing remote frame
Date: Wed, 4 Jun 2014 13:36:56 -0400

... and, this is a regression from 24.3, where I've been happily using multiple displays.

Ken

Message #14 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Wed, 04 Jun 2014 21:39:58 +0400

On 06/04/2014 09:09 PM, Ken Raeburn wrote:

> 1) Build Emacs with "lucid" toolkit because you like making frames on
>     multiple displays.
> 2) Fire up Emacs on your local X11 display :0.
> 3) ssh into the machine and use emacsclient to get a frame on display
>     :10 or whatever.
> 4) Drop the remote connection, or use your window manager to kill the
>     remote frame, or poke around in (current-frame-configuration) to find
>     the frame and apply delete-frame to it.
> 5) Watch your Emacs process die.

Can't reproduce (but I'm using Xnest on the same machine instead),
both for trunk and for 24.3.91.

Could you please try 1) Xnest instead of remote machine and 2) trunk
instead of 24.3.91?

Dmitry

Message #19 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Wed, 04 Jun 2014 17:38:12 -0400

Dmitry Antipov <dmantipov <at> yandex.ru> writes:
> Can't reproduce (but I'm using Xnest on the same machine instead),
> both for trunk and for 24.3.91.
>
> Could you please try 1) Xnest instead of remote machine and 2) trunk
> instead of 24.3.91?

I've tried Xnest locally and couldn't reproduce the problem initially.

I noticed the function frame-font-cache that can give a peek at the
cache content (aside: without making a copy... and we have C code that
will crash if the data structure is altered in naughty ways??) and took
a look at what I'm getting for the two displays.

For the remote XQuartz display, the cache has:

("localhost:12.0"
 (x 1
    (#<font-spec x misc fixed ## iso8859-1 nil nil nil nil nil nil nil
		 ((user-spec . "7x14"))
		 > .
		 [#<font-entity x misc fixed ## iso8859-1 medium r semicondensed 13 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r semicondensed 13 100 110 60 nil> ...a bunch more here...)
    (#<font-spec x nil 7x14 nil nil normal normal normal nil nil nil nil
		 ((:name . "7x14"))
		 > . #<font-entity x Misc Fixed ## ISO8859-1 medium r normal 14 75 110 70 nil>))
 (xft 1
      (#<font-spec xft misc fixed ## iso8859-1 nil nil nil nil nil nil nil
		   ((user-spec . "7x14"))
		   > .
		   [])
      (#<font-spec xft nil 7x14 nil nil normal normal normal nil nil nil nil
		   ((:name . "7x14"))
		   >)))

Note that the last one does indeed have nil instead of an array.

For the local display, the slots all contain (empty or non-empty) arrays:

(":0.0"
 (x 2
    (#<font-spec x nil Ubuntu\ Mono nil iso8859-1 nil nil nil nil nil nil nil
		 ((:name . "Ubuntu Mono 13"))
		 > .
		 [])
    (#<font-spec x unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil 100 nil
		 ((user-spec . "Ubuntu Mono 13"))
		 > .
		 [])
    (#<font-spec x unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil nil nil
		 ((:script . symbol))
		 > .
		 [])
    (#<font-spec x unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil nil nil
		 ((user-spec . "Ubuntu Mono 13"))
		 > .
		 []))
 (xft 2
      (#<font-spec xft unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil 100 nil
		   ((user-spec . "Ubuntu Mono 13"))
		   > .
		   [#<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  >])
      (#<font-spec xft unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil nil nil
		   ((:script . symbol))
		   > .
		   [#<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf" . 0)
				   (:script . symbol))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf" . 0)
				   (:script . symbol))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf" . 0)
				   (:script . symbol))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf" . 0)
				   (:script . symbol))
				  >])
      (#<font-spec xft unknown Ubuntu\ Mono nil iso10646-1 nil nil nil nil nil nil nil
		   ((user-spec . "Ubuntu Mono 13"))
		   > .
		   [#<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf" . 0)
				   (user-spec . "Ubuntu Mono 13"))
				  >])
      (#<font-spec xft nil Ubuntu\ Mono nil iso8859-1 nil nil nil nil nil nil nil
		   ((:name . "Ubuntu Mono 13"))
		   > .
		   [#<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf" . 0)
				   (:name . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf" . 0)
				   (:name . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 normal normal normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf" . 0)
				   (:name . "Ubuntu Mono 13"))
				  > #<font-entity xft unknown Ubuntu\ Mono nil iso10646-1 bold italic normal 0 nil 100 0
				  ((:font-entity "/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf" . 0)
				   (:name . "Ubuntu Mono 13"))
				  >])))

I noticed something I'd forgotten -- on the Mac, I have an old X
resources file setting "Emacs*font: 7x14", which is different from the
local desktop environment. If I run Xnest, and load one X resource:

  $ xrdb -load 
  Emacs*font: 7x14
  ^D
  $

and then pull up a remote frame and look at its cache, I do see some
7x14 entries under "x" that look okay, but under "xft", the last one
appears to have nil again:

 (xft 1
      (#<font-spec xft misc fixed ## iso8859-1 nil nil nil nil nil 110 nil
		   ((user-spec . "7x14"))
		   > .
		   [])
      (#<font-spec xft misc fixed ## iso10646-1 nil nil nil nil nil nil nil
		   ((:script . symbol))
		   > .
		   [])
      (#<font-spec xft misc fixed ## iso8859-1 nil nil nil nil nil nil nil
		   ((user-spec . "7x14"))
		   > .
		   [])
      (#<font-spec xft nil 7x14 nil nil normal normal normal nil nil nil nil
		   ((:name . "7x14"))
		   >)))

And when the Xnest connection went away, so did the Emacs process. So,
yeah, now I can reproduce it with Xnest...

Ken

Message #22 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Wed, 04 Jun 2014 17:49:58 -0400

A simpler reproduction just worked for me:

emacs -Q -nw

in the scratch buffer, evaluate:

(let ((f (make-frame-on-display ":0" '((font . "7x14")))))
  (delete-frame f))

That's killed my Emacs processes pretty reliably.

Simpler still:

$ emacs -Q -nw --eval '(let ((f (make-frame-on-display ":0" '"'"'((font . "7x14"))))) (delete-frame f))'

The terminal window gets a frame, the X display gets a frame, the X
frame goes away, and the terminal-mode Emacs crashes.

Ken

Message #25 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 05 Jun 2014 08:53:16 +0400

[Message part 1 (text/plain, inline)]

On 06/05/2014 01:49 AM, Ken Raeburn wrote:

> A simpler reproduction just worked for me:
>
> emacs -Q -nw
>
> in the scratch buffer, evaluate:
>
> (let ((f (make-frame-on-display ":0" '((font . "7x14")))))
>    (delete-frame f))
>
> That's killed my Emacs processes pretty reliably.
>
> Simpler still:
>
> $ emacs -Q -nw --eval '(let ((f (make-frame-on-display ":0" '"'"'((font . "7x14"))))) (delete-frame f))'
>
> The terminal window gets a frame, the X display gets a frame, the X
> frame goes away, and the terminal-mode Emacs crashes.

Please try this against emacs-24 branch or 24.3.91 (this is a backported
hybrid of trunk commits 116927 and 117126). If that works for you, this
should be incorporated into emacs-24 and included into the next pretest.

Dmitry

[bug17691.patch (text/x-patch, attachment)]

Message #28 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 05 Jun 2014 09:56:34 +0400

On 06/05/2014 08:53 AM, Dmitry Antipov wrote:

> Please try this against emacs-24 branch or 24.3.91 (this is a backported
> hybrid of trunk commits 116927 and 117126). If that works for you, this
> should be incorporated into emacs-24 and included into the next pretest.

BTW, could you please check one more thing for any of emacs-24, 24.3.91
or trunk and --with-x-toolkit=lucid:

gdb emacs
b XUnloadFont
r -Q --eval '(let ((f (make-frame-on-display ":0" '"'"'((font . "7x14"))))) (delete-frame f))'

When you hit the breakpoint, try to print data pointed by 'font'.
I'm seeing an invalid pointers, e.g.:

Breakpoint 1, XUnloadFont (dpy=0xb71180, font=25165832) at UnldFont.c:36
36	{
(gdb) bt 10
#0  XUnloadFont (dpy=0xb71180, font=25165832) at UnldFont.c:36
#1  0x0000003e79015689 in FreeCacheRec (app=app <at> entry=0x1276370, p=0x12f6ca8, prev=prev <at> entry=0x3e79265770 <cacheHashTable+272>)
    at Convert.c:449
#2  0x0000003e790168fb in _XtCacheFlushTag (app=0x1276370, tag=tag <at> entry=0x11ba4b0) at Convert.c:491
#3  0x0000003e7901e3ae in CloseDisplay (dpy=dpy <at> entry=0xb71180) at Display.c:638
#4  0x0000003e7901f09c in XtCloseDisplay (dpy=0xb71180) at Display.c:680
#5  0x000000000052fc25 in x_delete_terminal (terminal=0x1133030) at ../../emacs-24.3.91/src/xterm.c:10414
#6  0x000000000050b73f in Fdelete_terminal (terminal=18034741, force=11533218) at ../../emacs-24.3.91/src/terminal.c:348
#7  0x000000000041f036 in delete_frame (frame=18107005, force=11533170) at ../../emacs-24.3.91/src/frame.c:1399
#8  0x000000000041f564 in Fdelete_frame (frame=18107005, force=11533170) at ../../emacs-24.3.91/src/frame.c:1509
#9  0x00000000005f1789 in eval_sub (form=18902422) at ../../emacs-24.3.91/src/eval.c:2188
(More stack frames follow...)
(gdb) p *font
Cannot access memory at address 0x1800008
(gdb) c
Continuing.

Breakpoint 1, XUnloadFont (dpy=dpy <at> entry=0xb71180, font=25165825) at UnldFont.c:36
36	{
(gdb) bt 10
#0  XUnloadFont (dpy=dpy <at> entry=0xb71180, font=25165825) at UnldFont.c:36
#1  0x000000379461fd78 in XCloseDisplay (dpy=dpy <at> entry=0xb71180) at ClDisplay.c:59
#2  0x0000003e7901e4b5 in CloseDisplay (dpy=dpy <at> entry=0xb71180) at Display.c:664
#3  0x0000003e7901f09c in XtCloseDisplay (dpy=0xb71180) at Display.c:680
#4  0x000000000052fc25 in x_delete_terminal (terminal=0x1133030) at ../../emacs-24.3.91/src/xterm.c:10414
#5  0x000000000050b73f in Fdelete_terminal (terminal=18034741, force=11533218) at ../../emacs-24.3.91/src/terminal.c:348
#6  0x000000000041f036 in delete_frame (frame=18107005, force=11533170) at ../../emacs-24.3.91/src/frame.c:1399
#7  0x000000000041f564 in Fdelete_frame (frame=18107005, force=11533170) at ../../emacs-24.3.91/src/frame.c:1509
#8  0x00000000005f1789 in eval_sub (form=18902422) at ../../emacs-24.3.91/src/eval.c:2188
#9  0x00000000005ecb68 in Fprogn (body=18902454) at ../../emacs-24.3.91/src/eval.c:468
(More stack frames follow...)
(gdb) p *font
Cannot access memory at address 0x1800001

etc.

Dmitry

Message #31 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, 17691 <17691 <at> debbugs.gnu.org>
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 5 Jun 2014 15:47:19 -0400

[Message part 1 (text/plain, inline)]

With my one-liner test, using your patch, I finish up with a terminal
session (as expected) with an error message "Display :0 does not exist" in
the minibuffer (not expected). In the *Messages* buffer, it's recorded as
"get-device-terminal: Display :0 does not exist", though it didn't display
that way initially in the minibuffer.

I set a breakpoint on XUnloadFont as requested, and "font" doesn't appear
to be a valid pointer; is it supposed to be a resource id maybe?


On Thu, Jun 5, 2014 at 12:53 AM, Dmitry Antipov <dmantipov <at> yandex.ru> wrote:

> On 06/05/2014 01:49 AM, Ken Raeburn wrote:
>
>  A simpler reproduction just worked for me:
>>
>> emacs -Q -nw
>>
>> in the scratch buffer, evaluate:
>>
>> (let ((f (make-frame-on-display ":0" '((font . "7x14")))))
>>    (delete-frame f))
>>
>> That's killed my Emacs processes pretty reliably.
>>
>> Simpler still:
>>
>> $ emacs -Q -nw --eval '(let ((f (make-frame-on-display ":0" '"'"'((font .
>> "7x14"))))) (delete-frame f))'
>>
>> The terminal window gets a frame, the X display gets a frame, the X
>> frame goes away, and the terminal-mode Emacs crashes.
>>
>
> Please try this against emacs-24 branch or 24.3.91 (this is a backported
> hybrid of trunk commits 116927 and 117126). If that works for you, this
> should be incorporated into emacs-24 and included into the next pretest.
>
> Dmitry
>
>

[Message part 2 (text/html, inline)]

Message #34 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, 17691 <17691 <at> debbugs.gnu.org>
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 5 Jun 2014 17:09:49 -0400

[Message part 1 (text/plain, inline)]

Oh, sorry... I just noticed in gdb I'd used my one-liner command line, and
the one you asked me to run didn't use "-nw".

If I use the command line you suggested, when $DISPLAY is defined as :0, I
get one window, and briefly a second; XUnloadFont isn't hit, since I've
still got a window open on that display. But I assume closing the final
window as in my test was what you actually wanted...

Also, if I use the window manager to close the X window rather than
invoking delete-frame, the "display :0 does not exist" message doesn't
appear.

Ken


On Thu, Jun 5, 2014 at 3:47 PM, Ken Raeburn <raeburn <at> permabit.com> wrote:

> With my one-liner test, using your patch, I finish up with a terminal
> session (as expected) with an error message "Display :0 does not exist" in
> the minibuffer (not expected). In the *Messages* buffer, it's recorded as
> "get-device-terminal: Display :0 does not exist", though it didn't display
> that way initially in the minibuffer.
>
> I set a breakpoint on XUnloadFont as requested, and "font" doesn't appear
> to be a valid pointer; is it supposed to be a resource id maybe?
>
>
> On Thu, Jun 5, 2014 at 12:53 AM, Dmitry Antipov <dmantipov <at> yandex.ru>
> wrote:
>
>> On 06/05/2014 01:49 AM, Ken Raeburn wrote:
>>
>>  A simpler reproduction just worked for me:
>>>
>>> emacs -Q -nw
>>>
>>> in the scratch buffer, evaluate:
>>>
>>> (let ((f (make-frame-on-display ":0" '((font . "7x14")))))
>>>    (delete-frame f))
>>>
>>> That's killed my Emacs processes pretty reliably.
>>>
>>> Simpler still:
>>>
>>> $ emacs -Q -nw --eval '(let ((f (make-frame-on-display ":0" '"'"'((font
>>> . "7x14"))))) (delete-frame f))'
>>>
>>> The terminal window gets a frame, the X display gets a frame, the X
>>> frame goes away, and the terminal-mode Emacs crashes.
>>>
>>
>> Please try this against emacs-24 branch or 24.3.91 (this is a backported
>> hybrid of trunk commits 116927 and 117126). If that works for you, this
>> should be incorporated into emacs-24 and included into the next pretest.
>>
>> Dmitry
>>
>>
>

[Message part 2 (text/html, inline)]

Message #37 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, 17691 <17691 <at> debbugs.gnu.org>
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 12 Jun 2014 17:14:39 -0400

[Message part 1 (text/plain, inline)]

I've noticed Emacs doing a lot of garbage collection after I've lost a
remote network connection where I had an Emacs window displayed. (This is
Emacs 24.3.91 with the changes from Dmitry; without the changes the lost
connection would kill Emacs altogether.) Typically it seems to be GCing a
few times in the span of a couple seconds or so, mostly after I've typed
something. Each character seems to be enough to trigger it, so if I start
typing a line of text, the "Garbage collecting..." messages are constantly
flickering in the minibuffer.

I eventually traced it back to lots of invocations of timer callbacks;
while I'm still tracing down exactly why they're happening so much, I
noticed that the CPU utilization of Emacs is hovering around 100% now.
(It's sluggish but does still respond.) According to strace it seems to be
constantly doing this, over and over:

[pid  5736] 16:27:14.008209 clock_gettime(CLOCK_REALTIME, {1402604834,
8265741}) = 0
[pid  5736] 16:27:14.008428 pselect6(21, [7 8 10 11 12 13 16 18 20], [],
NULL, {45, 991734259}, {NULL, 8}) = 1 (in [20], left {45, 991729436})
[pid  5736] 16:27:14.008666 poll([{fd=11, events=POLLIN}], 1, 0) = 0
(Timeout)
[pid  5736] 16:27:14.008925 clock_gettime(CLOCK_REALTIME, {1402604834,
8985614}) = 0
[pid  5736] 16:27:14.009215 recvfrom(7, 0x3ef1ed4, 4096, 0, 0, 0) = -1
EAGAIN (Resource temporarily unavailable)

In this process, fd 20 is the dropped TCP connection for the remote
display, and fd 7 is the unix-domain socket to the local display. Since the
remote connection is closed, pselect6 returns immediately, but we never
drop it from the fd set.

I'm still trying to figure out if it's incorrectly firing an idle timer
handler each time around a loop or something like that, which might account
for the excessive garbage collection.

My test method:
1) Start (modified) Emacs on :0 in daemon mode via emacsclient -c -a "" -n
2) Use ssh to log into the desktop again with a different $DISPLAY
3) Use emacsclient to get an X11 window popped up
4) Use "~." to kill the ssh session
5) Use top, strace, etc to look at the spinning Emacs process

[Message part 2 (text/html, inline)]

Message #40 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: dmantipov <at> yandex.ru, 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Fri, 13 Jun 2014 09:05:38 +0300

> Date: Thu, 12 Jun 2014 17:14:39 -0400
> From: Ken Raeburn <raeburn <at> permabit.com>
> Cc: 17691 <17691 <at> debbugs.gnu.org>
> 
> I eventually traced it back to lots of invocations of timer callbacks;

What do you see in the 2 timers lists?

Message #43 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmantipov <at> yandex.ru, 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Fri, 13 Jun 2014 17:37:28 -0400

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

>> Date: Thu, 12 Jun 2014 17:14:39 -0400
>> From: Ken Raeburn <raeburn <at> permabit.com>
>> Cc: 17691 <17691 <at> debbugs.gnu.org>
>> 
>> I eventually traced it back to lots of invocations of timer callbacks;
>
> What do you see in the 2 timers lists?

Thanks to a list-timers function I've been developing to experiment with
tabulated-list-mode, here's the English form:

Time                   Repeat   Idle Trig? Callback
  idle      0.50s           t   idle   No  #[... eldoc stuff ...]
  idle      0.50s           t   idle   No  jit-lock-context-fontify
  idle      0.50s           t   idle   No  which-func-update
  idle      2.00s           t   idle   No  jabber-activity-clean
  idle      2.00s           t   idle   No  jabber-activity-clean
  idle     30.00s           t   idle   No  desktop-auto-save
  idle    120.00s           t   idle   No  my-desktop-save
  idle   3600.00s         nil   idle   No  gnus-demon-run-callback(#[... a callback of mine ...])
  idle   3600.00s         nil   idle   No  gnus-demon-run-callback(gnus-demon-scan-news 3600 7200 t)
2014-06-13 17:26:14        30    nil   No  jabber-whitespace-ping-do
2014-06-13 17:26:56        60    nil   No  p4-refresh-files-in-buffers
2014-06-13 17:27:00        60    nil   No  display-time-event-handler
2014-06-13 17:27:22       nil    nil   No  jabber-autoaway-timer
2014-06-13 17:30:14       600    nil   No  jabber-keepalive-do

(This clearly points out some cleanup I should do -- my-desktop-save is
probably redundant with desktop-auto-save, and jabber-activity-clean
doesn't need to be there twice.)

So the shortest idle-time delay is half a second, but once this problem
triggers, based on the garbage collection messages, *something* is
happening even if I'm typing a few characters per second without such
delays.

Ken

Message #46 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Wed, 18 Jun 2014 15:00:47 -0700

> In this process, fd 20 is the dropped TCP connection for the remote
> display, and fd 7 is the unix-domain socket to the local display. Since the
> remote connection is closed, pselect6 returns immediately, but we never
> drop it from the fd set.

I tried to reproduce the problem on Fedora 20 x86-64, using your recipe 
and the Emacs-24 branch, but could not.  Perhaps it's something to do 
with the other stuff you're running, or it could be that I haven't 
applied Dmitry's patch.

Anyway, this latest problem looks related to Bug#17647 and Bug#17805. 
Can you easily reproduce the problem?  Does the patch proposed in 
Bug#17805 Message #8 fix it?  Here's a URL:

http://debbugs.gnu.org/cgi/bugreport.cgi?msg=8;filename=17805.diff;att=1;bug=17805

Message #51 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Fri, 20 Jun 2014 22:52:57 -0400

On Jun 18, 2014, at 18:00, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

>> In this process, fd 20 is the dropped TCP connection for the remote
>> display, and fd 7 is the unix-domain socket to the local display. Since the
>> remote connection is closed, pselect6 returns immediately, but we never
>> drop it from the fd set.
> 
> I tried to reproduce the problem on Fedora 20 x86-64, using your recipe and the Emacs-24 branch, but could not.  Perhaps it's something to do with the other stuff you're running, or it could be that I haven't applied Dmitry's patch.

Specifying "lucid" toolkit?

I'm using 24.3.91 as packaged up for ftp, not the current emacs-24 branch. And without Dmitry's change, I couldn't close out the second display without losing Emacs completely; I'm surprised you don't see it.

I'm using the automatic desktop restoration, so it restores one or more windows on startup; I can't think off the top of my head what else would affect the displays much. Oh, I also tweaked some faces to display things in reduced size (mode lines, certain buffers' contents), which I imagine might cause more font lookup requests or something.

> 
> Anyway, this latest problem looks related to Bug#17647 and Bug#17805. Can you easily reproduce the problem?  Does the patch proposed in Bug#17805 Message #8 fix it?  Here's a URL:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=8;filename=17805.diff;att=1;bug=17805

This doesn't seem to make a difference. When I kill the ssh session over which I'm displaying one of the Emacs X11 windows, the Emacs process still goes to 100% CPU utilization, and lots of garbage collection when I type.


I've done a few more experiments and found a few interesting things:

Some issues in my own configuration: An auto-save-hook that triggered desktop code that would allocate stuff. A 60-second repeating timer that ran uncompiled code in lots of buffers.

In Emacs: Since Emacs keeps looping polling the socket with the closed X11 session, and the loop in keyboard.c includes a call to timer_check, it's calling timer_check a lot, and that function always copies the current timer-list sequence and sometimes the idle timers too. After I'd disabled some timers, and did some instrumentation under gdb, I found that timer_check would be called around 22000 times in the space of about 15 seconds -- over 1000 times a second -- and that's with gdb breakpoints getting triggered on every call.

In another Emacs process, after I've cleaned up some stuff, once I set up the lost X11 session to trigger this busy loop, it looks like timer_check causes consing_since_gc to keep growing, but garbage collection doesn't actually happen until either a timer fires (causing call1 to be invoked on the timer handler function, which triggers a maybe_gc call) or I type a key or cause another input event (command_loop_1 invokes pre-command-hooks via safe_run_hooks which indirectly calls call0 and thus maybe_gc). In one instance, consing_since_gc got up to 3833040 before a timer fired, but gc_cons_threshold was 800000 and gc_relative_threshold was 3098800, so maybe_gc, had it been invoked, would've run GC before that point.

This wouldn't really be an issue if not for the busy loop while waiting for input.

Also, opening and closing tty frames don't trigger the problem, only X11 frames.

Ken

Message #54 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Sat, 21 Jun 2014 11:21:57 -0700

Ken Raeburn wrote:
> Specifying "lucid" toolkit?

I think so.  I've discarded that test now and anyway am away from the 
desktop where I tested it, so I'm not sure.

> I'm using 24.3.91 as packaged up for ftp, not the current emacs-24 branch.

Some changes have been made in that area since then; I have no idea if 
they're related to any fix.  If you like, you try get the current 
emacs-24 tarball (bzr 117280, dated 2014-06-21 18:08:18 +0300) from:

http://cs.ucla.edu/~eggert/emacs-24-117280.tgz

> I'm using the automatic desktop restoration

I'm not.  I followed the recipe at the end of 
<http://bugs.gnu.org/17691#37>.  It might be better to use emacs -Q in 
any recipe.

Message #57 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Sun, 22 Jun 2014 03:03:49 -0400

On Jun 21, 2014, at 14:21, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> Ken Raeburn wrote:
>> Specifying "lucid" toolkit?
> 
> I think so.  I've discarded that test now and anyway am away from the desktop where I tested it, so I'm not sure.

Ah, my mistake, sorry... I'm mis-remembering the failure modes. The crash on close came from a bug in font handling that was somehow dependent on the fonts I was using. Between that and my init file at work...

I started a new experiment from scratch -- rebuilt from source on a new GNU/Linux box, using an account with no Emacs init files, two ssh sessions into the machine both forwarding X11 connections (from a Mac with a few X resources loaded but no font specified). Started "emacs" or "emacs -Q" (I tried both ways) in one session, invoked server-start, then in the other ssh session, ran emacsclient -c -n, and after the window popped up, killed the ssh session with "~.", and Emacs went to 100% CPU utilization. If I set garbage-collection-messages to t, I would get the messages frequently. The only timers visible to Lisp are two idle timers, for jit-lock and cursor blinking.

This happens with 24.3.91, both with and without Dmitry's patch. So, technically, this busy loop is a different bug from the crash that started this report, though both are caused by losing X11 connections. (Let me know if you'd rather I open a new bug report on just this busy-loop problem.)

Closing the window via the window manager, instead of killing the TCP connection, doesn't result in excessive CPU use.

I tried switching to the emacs-24 branch. I've already got a git mirror on that machine, so I built from the sources as of this commit:

   Author: Glenn Morris <rgm <at> gnu.org>
   Date:   Sat Jun 21 14:36:44 2014 -0700

     * landmark.el: Commentary fixes.

I ran configured with --with-x-toolkit=lucid and a prefix, bootstrapped, emacs -Q, etc., as above, and Emacs again went to 100% CPU utilization.


I've looked at the emacs-24 branch code around connection shutdown a little more. If I use the window manager to get rid of a window, that's sending a message through Emacs and it's deleting a frame and (for the last window on the display) calling XtCloseDisplay and so on, by way of x_delete_frame in xterm.c. If the connection is lost, instead, then x_connection_closed clears dpyinfo->display, so x_delete_frame has no connection handle to pass to XtCloseDisplay, and it has no file descriptor number to pass to delete_keyboard_wait_descriptor.

As a test, I put a quick hack into x_connection_closed to call delete_keyboard_wait_descriptor() on the file descriptor associated with the lost connection, and it stopped the spinning from happening, but of course it still doesn't do any of the Xt cleanup.

Paul, if my test recipe works for you without causing the excess CPU use, maybe for you it's managing to call delete_keyboard_wait_descriptor on some path that it's not getting to for me, for some reason?

Ken

Message #60 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Sun, 22 Jun 2014 12:14:31 -0700

Thanks, I can reproduce the problem on the emacs-24 branch with your 
latest recipe.  I don't offhand know how to fix it, though.

Message #63 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Sat, 02 Aug 2014 14:34:03 -0700

I looked into this a bit more, came up with a fix that works for me, and 
installed it as emacs-24 bzr 117420.  Please give it a try.

Message #70 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 7 Aug 2014 01:06:11 -0400

On Aug 2, 2014, at 17:34, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> I looked into this a bit more, came up with a fix that works for me, and installed it as emacs-24 bzr 117420.  Please give it a try.

Yes, the branch now handles my test situation without the excessive CPU use, although it does accumulate file descriptors in CLOSE_WAIT state from the lost X11 connections.

Ken

Message #73 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Wed, 06 Aug 2014 22:23:39 -0700

Ken Raeburn wrote:
> Yes, the branch now handles my test situation without the excessive CPU use, although it does accumulate file descriptors in CLOSE_WAIT state from the lost X11 connections.

We should fix that too, I guess.  Does Emacs 24.3 have this file 
descriptor leak too?  If so, it's not a regression and any fix should be 
in the trunk.

Message #76 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 7 Aug 2014 02:02:18 -0400

On Aug 7, 2014, at 01:23, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> Ken Raeburn wrote:
>> Yes, the branch now handles my test situation without the excessive CPU use, although it does accumulate file descriptors in CLOSE_WAIT state from the lost X11 connections.
> 
> We should fix that too, I guess.  Does Emacs 24.3 have this file descriptor leak too?  If so, it's not a regression and any fix should be in the trunk.

Yes, the leak appears to be an older problem.

Ken

Message #79 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17691 <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 07 Aug 2014 08:26:32 -0400

>> We should fix that too, I guess.  Does Emacs 24.3 have this file
>> descriptor leak too?  If so, it's not a regression and any fix should be
>> in the trunk.
> Yes, the leak appears to be an older problem.

Maybe it's related to our hack that tries to avoiding closing
connections when built with Gtk to avoid the infamous Gtk bug.


        Stefan

Message #84 received at 17691-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 
 Ken Raeburn <raeburn <at> permabit.com>
Cc: 17691-done <at> debbugs.gnu.org
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 07 Aug 2014 07:36:44 -0700

Stefan Monnier wrote:
> Maybe it's related to our hack that tries to avoiding closing
> connections when built with Gtk to avoid the infamous Gtk bug.

It's related, bug that hack calls emacs_abort in this situation, so 
there's no problem with leaked file descriptors after *that*.  Fixing 
and/or working-around the Gtk bug would be a much bigger deal.

Anyway, I installed a patch for the non-Gtk platforms, as trunk bzr 
117664, and am closing the bug.

Previous Next

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