bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Ken Raeburn-5

(Yet another attempt to send while fighting with customize over my email
options...)

This is a simplified version of a crash I got using emacsclient, daemon
mode, and desktop-save-mode. My saved desktop configuration somehow has
frames with different names for the same local display, perhaps because
window manager buttons I use to invoke emacsclient cause ":0.0" to be
used, and my xterm shells have DISPLAY set to ":0".

Emacs is compiled with "--enable-checking --with-x-toolkit=lucid".

Recipe:
 1. emacs -Q --daemon
 2. DISPLAY=:0 emacsclient -c -n
 3. DISPLAY=:0.0 emacsclient -c -n
 4. Use a window-manager button to delete the first Emacs window.
 5. Emacs crashes with an assertion failure.

(gdb) bt full
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:350
No locals.
#1  0x000000000057fc24 in die (msg=<optimized out>, file=<optimized out>, line=<optimized out>) at alloc.c:6833
No locals.
#2  0x00000000004ea74d in xim_close_dpy (dpyinfo=0xd14520) at xterm.c:8007
        ret = <optimized out>
        xim_inst = 0xcf5560
#3  x_delete_terminal (terminal=<optimized out>) at xterm.c:10376
        dpyinfo = 0xd14520
        connection = -1
#4  0x00000000004ddfe2 in Fdelete_terminal (terminal=18228141, force=<optimized out>) at terminal.c:348
        t = 0x11623a8
#5  0x0000000000423756 in delete_frame (frame=<optimized out>, force=<optimized out>) at frame.c:1399
        tmp = 6
        terminal = 0x11623a8
        f = 0x127ee38
        sf = 0xc9b268
        kb = 0x0
        minibuffer_selected = <optimized out>
        is_tooltip_frame = 0
#6  0x00000000005a16fe in Ffuncall (nargs=<optimized out>, args=0x7fff1460f978) at eval.c:2818
        fun = 9051333
        original_fun = <optimized out>
        funcar = 66
        numargs = <optimized out>
        val = <optimized out>
        internal_args = 0x7fff1460f980
        i = <optimized out>
#7  0x00000000005e055d in exec_byte_code (bytestr=66, vector=2147483647, maxdepth=139883996531360, args_template=54, nargs=3, args=0x0) at bytecode.c:916
        targets = {0x5e05f1, 0x5e0e35, 0x5e0e3a, 0x5e0e3f, 0x5e03b2, 0x5e03b8, 0x5e1baa, 0x5e1bf0, 0x5e1c78, 0x5e1c7d, 0x5e1c49, 0x5e1c4e, 0x5e03f9, 0x5e0400, 0x5e0b35, 0x5e1c53, 0x5e0d4a, 0x5e0d4f, 0x5e0cc2, 0x5e0cc7, 0x5e046c, 0x5e0470, 0x5e0c67, 0x5e0c42, 0x5e0b1a, 0x5e0b1f, 0x5e0b24, 0x5e0b29, 0x5e04f1, 0x5e04f8, 0x5e0cae, 0x5e0af5, 0x5e0ae4, 0x5e0ae9, 0x5e0aee, 0x5e0aba, 0x5e0537, 0x5e0540, 0x5e0aa6, 0x5e0abf, 0x5e1e0f, 0x5e1e14, 0x5e1e19, 0x5e1de5, 0x5e0580, 0x5e0580, 0x5e1da5, 0x5e1dea, 0x5e0995, 0x5e098a, 0x5e083e, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e1fca, 0x5e206b, 0x5e20a6, 0x5e25cc, 0x5e2607, 0x5e0c00, 0x5e0ccc, 0x5e264f, 0x5e0bc2, 0x5e0d0c, 0x5e2684, 0x5e23e0, 0x5e240f, 0x5e244f, 0x5e248c, 0x5e2516, 0x5e2545, 0x5e2585, 0x5e21c8, 0x5e21f7, 0x5e29da, 0x5e2a1a, 0x5e28dc, 0x5e291c, 0x5e2960, 0x5e299d, 0x5e26c4, 0x5e2751, 0x5e278d, 0x5e27cd, 0x5e2897, 0x5e280d, 0x5e2852, 0x5e142c, 0x5e1471, 0x5e14ae, 0x5e14e3, 0x5e1520, 0x5e155d, 0x5e159a, 0x5e1654, 0x5e05c3, 0x5e16ae, 0x5e16dd, 0x5e175a, 0x5e17b4, 0x5e180e, 0x5e1839, 0x5e186a, 0x5e189b, 0x5e18ec, 0x5e05f1, 0x5e191e, 0x5e1953, 0x5e1988, 0x5e19bd, 0x5e19f2, 0x5e1a27, 0x5e05c3, 0x5e05f1, 0x5e1a56, 0x5e1a9d, 0x5e1acc, 0x5e1afb, 0x5e1b3b, 0x5e1b7b, 0x5e102f, 0x5e10e8, 0x5e13ac, 0x5e13ec, 0x5e1128, 0x5e115d, 0x5e05f1, 0x5e0773, 0x5e1e25, 0x5e0b49, 0x5e1eb5, 0x5e2226, 0x5e2299, 0x5e0720, 0x5e06ff, 0x5e0c7b, 0x5e063c, 0x5e0d54, 0x5e07cb, 0x5e07f9, 0x5e09c3, 0x5e0a13, 0x5e0a57, 0x5e1f69, 0x5e1db9, 0x5e1188, 0x5e11cf, 0x5e11fe, 0x5e122d, 0x5e125c, 0x5e128b, 0x5e12cb, 0x5e130b, 0x5e134b, 0x5e138b, 0x5e0e45, 0x5e0e85, 0x5e0ec5, 0x5e0ef4, 0x5e0f34, 0x5e0f74, 0x5e0fb3, 0x5e0ff2, 0x5e15d7, 0x5e1614, 0x5e0db9, 0x5e0e00, 0x5e05f1, 0x5e20e1, 0x5e215e, 0x5e2346, 0x5e2a5a, 0x5e066a, 0x5e24c9, 0x5e2701, 0x5e170e, 0x5e1c82, 0x5e1cc7, 0x5e05f1, 0x5e05f1, 0x5e1d1f, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e1d6a <repeats 64 times>}
        count = 8
        stack = {
          pc = 0xb8211e "\202\070",
          byte_string = 10257961,
          byte_string_start = 0xb820eb "\304\b!\211@\262\001\305\306 \031\032\033\t\203)",
          next = 0x7fff1460fdf0
        }
        result = 66
        type = 4
#8  0x00000000005a0f92 in funcall_lambda (fun=10257909, nargs=<optimized out>, arg_vector=0x7fff1460fb88) at eval.c:3049
        val = <optimized out>
        syms_left = <optimized out>
        next = 5
        lexenv = 13137010
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
#9  0x00000000005a1324 in Ffuncall (nargs=<optimized out>, args=0x7fff1460fb80) at eval.c:2876
        fun = <optimized out>
        original_fun = 13496946
        funcar = 66
        numargs = <optimized out>
        val = <optimized out>
        internal_args = <optimized out>
        i = <optimized out>
#10 0x000000000059ccb9 in Fcall_interactively (function=13496946, record_flag=13137010, keys=140733535288128) at callint.c:836
        val = <optimized out>
        args = 0x7fff1460fb80
        visargs = <optimized out>
        specs = <optimized out>
        filter_specs = <optimized out>
        teml = <optimized out>
        up_event = 13137010
        enable = 2
        next_event = <optimized out>
        prefix_arg = 13137010
        string = <optimized out>
        tem = <optimized out>
        varies = 0x7fff1460fb40 ""
        i = <optimized out>
        nargs = <optimized out>
        mark = <optimized out>
        arg_from_tty = <optimized out>
        key_count = 1
        record_then_fail = false
        save_this_command = 13137010
        save_last_command = 13179570
        save_this_original_command = 13137010
        save_real_this_command = 13137010
#11 0x00000000005a16c6 in Ffuncall (nargs=<optimized out>, args=0x7fff1460fd78) at eval.c:2822
        fun = 12550661
        original_fun = <optimized out>
        funcar = 66
        numargs = <optimized out>
        val = <optimized out>
        internal_args = 0x7fff1460fd80
        i = <optimized out>
#12 0x00000000005e055d in exec_byte_code (bytestr=66, vector=2147483647, maxdepth=139883996531360, args_template=108, nargs=4, args=0x0) at bytecode.c:916
        targets = {0x5e05f1, 0x5e0e35, 0x5e0e3a, 0x5e0e3f, 0x5e03b2, 0x5e03b8, 0x5e1baa, 0x5e1bf0, 0x5e1c78, 0x5e1c7d, 0x5e1c49, 0x5e1c4e, 0x5e03f9, 0x5e0400, 0x5e0b35, 0x5e1c53, 0x5e0d4a, 0x5e0d4f, 0x5e0cc2, 0x5e0cc7, 0x5e046c, 0x5e0470, 0x5e0c67, 0x5e0c42, 0x5e0b1a, 0x5e0b1f, 0x5e0b24, 0x5e0b29, 0x5e04f1, 0x5e04f8, 0x5e0cae, 0x5e0af5, 0x5e0ae4, 0x5e0ae9, 0x5e0aee, 0x5e0aba, 0x5e0537, 0x5e0540, 0x5e0aa6, 0x5e0abf, 0x5e1e0f, 0x5e1e14, 0x5e1e19, 0x5e1de5, 0x5e0580, 0x5e0580, 0x5e1da5, 0x5e1dea, 0x5e0995, 0x5e098a, 0x5e083e, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e1fca, 0x5e206b, 0x5e20a6, 0x5e25cc, 0x5e2607, 0x5e0c00, 0x5e0ccc, 0x5e264f, 0x5e0bc2, 0x5e0d0c, 0x5e2684, 0x5e23e0, 0x5e240f, 0x5e244f, 0x5e248c, 0x5e2516, 0x5e2545, 0x5e2585, 0x5e21c8, 0x5e21f7, 0x5e29da, 0x5e2a1a, 0x5e28dc, 0x5e291c, 0x5e2960, 0x5e299d, 0x5e26c4, 0x5e2751, 0x5e278d, 0x5e27cd, 0x5e2897, 0x5e280d, 0x5e2852, 0x5e142c, 0x5e1471, 0x5e14ae, 0x5e14e3, 0x5e1520, 0x5e155d, 0x5e159a, 0x5e1654, 0x5e05c3, 0x5e16ae, 0x5e16dd, 0x5e175a, 0x5e17b4, 0x5e180e, 0x5e1839, 0x5e186a, 0x5e189b, 0x5e18ec, 0x5e05f1, 0x5e191e, 0x5e1953, 0x5e1988, 0x5e19bd, 0x5e19f2, 0x5e1a27, 0x5e05c3, 0x5e05f1, 0x5e1a56, 0x5e1a9d, 0x5e1acc, 0x5e1afb, 0x5e1b3b, 0x5e1b7b, 0x5e102f, 0x5e10e8, 0x5e13ac, 0x5e13ec, 0x5e1128, 0x5e115d, 0x5e05f1, 0x5e0773, 0x5e1e25, 0x5e0b49, 0x5e1eb5, 0x5e2226, 0x5e2299, 0x5e0720, 0x5e06ff, 0x5e0c7b, 0x5e063c, 0x5e0d54, 0x5e07cb, 0x5e07f9, 0x5e09c3, 0x5e0a13, 0x5e0a57, 0x5e1f69, 0x5e1db9, 0x5e1188, 0x5e11cf, 0x5e11fe, 0x5e122d, 0x5e125c, 0x5e128b, 0x5e12cb, 0x5e130b, 0x5e134b, 0x5e138b, 0x5e0e45, 0x5e0e85, 0x5e0ec5, 0x5e0ef4, 0x5e0f34, 0x5e0f74, 0x5e0fb3, 0x5e0ff2, 0x5e15d7, 0x5e1614, 0x5e0db9, 0x5e0e00, 0x5e05f1, 0x5e20e1, 0x5e215e, 0x5e2346, 0x5e2a5a, 0x5e066a, 0x5e24c9, 0x5e2701, 0x5e170e, 0x5e1c82, 0x5e1cc7, 0x5e05f1, 0x5e05f1, 0x5e1d1f, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e05f1, 0x5e1d6a <repeats 64 times>}
        count = 3
        stack = {
          pc = 0xba1f82 "\006\006\071\203\233",
          byte_string = 10002481,
          byte_string_start = 0xba1f0e "\306\020\211?\205\f",
          next = 0x0
        }
        result = 66
        type = 13
#13 0x00000000005a1324 in Ffuncall (nargs=<optimized out>, args=0x7fff1460fed0) at eval.c:2876
        fun = <optimized out>
        original_fun = 13180898
        funcar = 66
        numargs = <optimized out>
        val = <optimized out>
        internal_args = <optimized out>
        i = <optimized out>
#14 0x00000000005a1909 in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>) at eval.c:2663
        ret_ungc_val = 66
        args = {13180898, 13496946, 13137010, 16481285, 13137058}
#15 0x00000000005274fe in read_char (commandflag=1, map=17049222, prev_event=13137010, used_mouse_menu=0x7fff146102cf, end_time=0x0) at keyboard.c:2944
        prev_buffer = 0xc8dd50
        c = 17533830
        local_getcjmp = {{
            __jmpbuf = {13137010, 1302660280949707907, 0, 19394104, 17049222, 0, -1302152121081228157, 1302661719464907907},
            __mask_was_saved = 0,
            __saved_mask = {
              __val = {0, 0, 0, 0, 0, 0, 0, 13163856, 5859230, 0, 0, 0, 0, 13163856, 13163856, 192}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
            __mask_was_saved = 0,
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        tem = 13496946
        save = <optimized out>
        previous_echo_area_message = 13137010
        also_record = 13137010
        reread = false
        polling_stopped_here = false
        orig_kboard = 0xd14f40
#16 0x00000000005295a4 in read_key_sequence (keybuf=0x7fff14610320, prompt=13137010, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, bufsize=30) at keyboard.c:9088
        interrupted_kboard = 0xd14f40
        interrupted_frame = 0x127ee38
        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 = 17049222
        first_event = 13137010
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 20457062,
          map = 20457062,
          start = 0,
          end = 0
        }
        keytran = {
          parent = 13116998,
          map = 13116998,
          start = 0,
          end = 0
        }
        indec = {
          parent = 20426022,
          map = 20426022,
          start = 0,
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = 13137010
        original_uppercase = 13305986
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0xc8dd50
        fake_prefixed_keys = 13137010
#17 0x000000000052b0c2 in command_loop_1 () at keyboard.c:1452
        cmd = <optimized out>
        keybuf = {17051382, 140733535290128, 4294967296, 0, 0, -6929747409077133824, 0, 9649312, 17429874, 2, 4611686018595160064, 4611686019484352512, 140733535290432, 5898849, 139883992655744, 139884077191168, 0, 0, 0, 336, 0, 5808116, 13306946, 13615984, 13137010, 13306946, 13615984, 5819474, 64, 5897286}
        i = <optimized out>
        prev_modiff = 11
        prev_buffer = 0xc8dd50
#18 0x000000000059f2a2 in internal_condition_case (bfun=0x52ae70 <command_loop_1>, handlers=<optimized out>, hfun=0x5200f0 <cmd_error>) at eval.c:1354
        val = <optimized out>
        c = 0xffffffffffffffc6
#19 0x000000000051cc2e in command_loop_2 (ignore=<optimized out>) at keyboard.c:1177
        val = 66
#20 0x000000000059f1a8 in internal_catch (tag=<error reading variable: Cannot access memory at address 0xffffffffffffffce>, func=0x51cc10 <command_loop_2>, arg=13137010) at eval.c:1118
        val = <optimized out>
        c = 0xffffffffffffffc6
#21 0x000000000051fc07 in command_loop () at keyboard.c:1156
No locals.
#22 recursive_edit_1 () at keyboard.c:777
        val = 3
#23 0x000000000051ff55 in Frecursive_edit () at keyboard.c:848
        buffer = <optimized out>
#24 0x0000000000411a95 in main (argc=3, 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 = 0xccacd6 ""

Lisp Backtrace:
"delete-frame" (0x1460f980)
"handle-delete-frame" (0x1460fb88)
"call-interactively" (0x1460fd80)
"command-execute" (0x1460fed8)

In stack frame 4 the terminal we're deleting has a name of ":0" and a
certain X11 "Display" structure pointer. The other frame (found via
Vframe_list) has a different terminal structure with a name of ":0.0"
and a different X11 display pointer (and even a different file
descriptor number, so we've got two connections open, also a bug, but
less important).

The crash is in an assertion in xim_close_display, called from
x_delete_terminal:

          Bool ret = XUnregisterIMInstantiateCallback
            (dpyinfo->display, dpyinfo->xrdb, xim_inst->resource_name,
             emacs_class, xim_instantiate_callback,
             (XRegisterIMInstantiateCallback_arg6) xim_inst);
          eassert (ret == True);

Why XUnregisterIMInstantiateCallback would fail, I don't know. There's
an assertion at the XRegisterIMInstantiateCallback call as well which
didn't get triggered.




In GNU Emacs 24.3.92.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-06-27 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.92.precise
 --with-x-toolkit=lucid --enable-checking'

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:
<backspace> SPC o v e r SPC m y SPC m a i l SPC s e
t t i n g s . SPC O <backspace> A p o l o g i e s SPC
i f SPC m u l t i p l e SPC o f SPC t h e <M-backspace>
<M-backspace> c o p i e s SPC a c t u a l l y SPC g
o t SPC t h r o u g h . <help-echo> <down-mouse-1>
<mouse-1> <help-echo> <switch-frame> <switch-frame>
C-a C-c C-c y e s <return> <help-echo> <help-echo>
<help-echo> <help-echo> <switch-frame> <down-mouse-5>
<mouse-5> <down-mouse-4> <mouse-4> <double-down-mouse-4>
<double-mouse-4> <down-mouse-4> <mouse-4> <down-mouse-4>
<mouse-4> <down-mouse-4> <mouse-4> <down-mouse-4> <mouse-4>
<down-mouse-4> <mouse-4> <down-mouse-4> <mouse-4> <down-mouse-4>
<mouse-4> <down-mouse-4> <mouse-4> <down-mouse-4> <mouse-4>
<down-mouse-4> <mouse-4> <down-mouse-4> <mouse-4> <down-mouse-4>
<mouse-4> <down-mouse-4> <mouse-4> <double-down-mouse-4>
<double-mouse-4> <help-echo> <help-echo> <down-mouse-1>
<mouse-movement> <mouse-1> C-h f r e p o r t - e m
<tab> <return> <help-echo> <help-echo> <help-echo>
<down-mouse-2> <mouse-1> <help-echo> C-x 1 C-u C-l
C-x 2 M-< C-s s e n d - m a i l - f u n c t i o n C-s
C-s C-s C-a C-l M-: m e s s a g e - s e n d - m a i
l - f u n c t i o n <return> C-h v m e s s a g e -
s e n d - m a i l - f u n <tab> <return> C-x 1 <help-echo>
<help-echo> <help-echo> <down-mouse-2> <mouse-1> <down-mouse-1>
<mouse-1> <help-echo> C-u C-p C-u C-p C-p C-u C-f C-u
C-f C-u C-f C-f C-f <return> C-u C-f C-u C-f C-f C-f
<return> n <help-echo> <switch-frame> <switch-frame>
<help-echo> <switch-frame> <down-mouse-1> <mouse-movement>
<mouse-1> <down-mouse-1> <mouse-1> <escape> x r e p
o r t - e m <tab> <return>

Recent messages:
Mark saved where search started
message-send-mail-with-mailclient
Type "q" to restore previous buffer, M-x scroll-up to scroll help.
Creating customization items...
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
Saving file /permabit/user/raeburn/.emacs...
Delete excess backup versions of /permabit/user/raeburn/.emacs? (y or n) n
Wrote /permabit/user/raeburn/.emacs [2 times]

Load-path shadows:
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-festival hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-festival
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-chat hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-chat
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-bookmarks hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-bookmarks
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ahc-presence hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ahc-presence
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-chatbuffer hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-chatbuffer
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-roster hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-roster
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-core hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-core
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ft-common hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ft-common
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-presence hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-presence
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-si-server hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-si-server
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-autoloads hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-autoloads
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-truncate hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-truncate
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ft-server hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ft-server
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-conn hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-conn
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-sasl hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-sasl
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/fsm hides /usr/share/emacs/site-lisp/emacs-jabber/fsm
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ft-client hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ft-client
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-xmessage hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-xmessage
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-chatstates hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-chatstates
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-export hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-export
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-time hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-time
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-screen hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-screen
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-autoaway hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-autoaway
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-compose hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-compose
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber hides /usr/share/emacs/site-lisp/emacs-jabber/jabber
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-modeline hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-modeline
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-activity hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-activity
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/srv hides /usr/share/emacs/site-lisp/emacs-jabber/srv
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-events hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-events
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-version hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-version
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-feature-neg hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-feature-neg
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-menu hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-menu
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-history hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-history
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-avatar hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-avatar
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-muc hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-muc
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-watch hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-watch
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-xml hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-xml
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-muc-nick-completion hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-muc-nick-completion
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-alert hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-alert
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-osd hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-osd
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ourversion hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ourversion
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-si-client hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-si-client
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-util hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-util
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-widget hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-widget
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-vcard hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-vcard
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-keepalive hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-keepalive
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-register hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-register
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-iq hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-iq
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-awesome hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-awesome
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-browse hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-browse
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ratpoison hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ratpoison
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-si-common hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-si-common
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-wmii hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-wmii
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-disco hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-disco
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-search hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-search
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-keymap hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-keymap
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-gmail hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-gmail
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-socks5 hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-socks5
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-vcard-avatars hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-vcard-avatars
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-private hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-private
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-sawfish hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-sawfish
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-ahc hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-ahc
/permabit/user/raeburn/.emacs.d/elpa/jabber-20140523.153/jabber-logon hides /usr/share/emacs/site-lisp/emacs-jabber/jabber-logon
~/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.92.precise/share/emacs/24.3.92/lisp/loaddefs

Features:
(jka-compr find-func mailalias mailclient qp cus-edit cus-start cus-load
ielm help-mode pp shadow sort mail-extr gnus-msg emacsbug sendmail
misearch multi-isearch mule-util bug-reference make-mode flyspell ispell
git-commit-mode server log-edit easy-mmode pcvs-util add-log sh-script
smie executable systemtap-mode cc-awk python vc-git hideshow cc-langs
cc-mode cc-fonts cc-guess cc-menus cc-cmds autorevert filenotify rcirc
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 484925 57300)
 (symbols 48 39723 7)
 (miscs 40 64472 15015)
 (strings 32 82028 10941)
 (string-bytes 1 2721256)
 (vectors 16 36334)
 (vector-slots 8 860235 28377)
 (floats 8 377 354)
 (intervals 56 24052 396)
 (buffers 960 177)
 (heap 1024 71290 2347))



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/08/2014 11:59 PM, Ken Raeburn wrote:

> This is a simplified version of a crash I got using emacsclient, daemon
> mode, and desktop-save-mode. My saved desktop configuration somehow has
> frames with different names for the same local display, perhaps because
> window manager buttons I use to invoke emacsclient cause ":0.0" to be
> used, and my xterm shells have DISPLAY set to ":0".
>
> Emacs is compiled with "--enable-checking --with-x-toolkit=lucid".
>
> Recipe:
>   1. emacs -Q --daemon
>   2. DISPLAY=:0 emacsclient -c -n
>   3. DISPLAY=:0.0 emacsclient -c -n
>   4. Use a window-manager button to delete the first Emacs window.
>   5. Emacs crashes with an assertion failure.
Reproduced. The whole thing looks like a mystery (perhaps Xlib makes a
difference between :0 and :0.0 somewhere in its innards), but this
workaround works for me. Can you please try it too?

Dmitry



bug17975.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Ken Raeburn-5

Dmitry Antipov <[hidden email]> writes:
> Reproduced. The whole thing looks like a mystery (perhaps Xlib makes a
> difference between :0 and :0.0 somewhere in its innards), but this
> workaround works for me. Can you please try it too?

It works for me too. Of course, my saved .emacs.desktop already has a
mix of display names in it; I'll have to get them in sync.

But of course it isn't going to address some reasonable uses of
make-frame-on-display (including perhaps old scripts some of us may have
lying around that invoke make-frame-on-display by way of emacsclient
--eval). Perhaps a similar change can be made within the main Emacs
code?

I can reformulate the recipe in a form without emacsclient, for testing
purposes:

 $ DISPLAY=:0 emacs -Q --eval \
 '(let ((f (selected-frame))) (make-frame-on-display ":0.0") (delete-frame f))'

If I use "(make-frame)" instead, or give make-frame-on-display the
initial DISPLAY value, it works fine.

It appears that mixing ":0" and "unix:0" can trigger the problem, too.
At least in my X11 environment, ":0" or ":0.0" seem to be the preferred
forms. So launching a non-daemon Emacs from xterm and then using the
modified emacsclient with it could also be a problem, but I haven't
tested it yet.

Ken



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/12/2014 01:22 AM, Ken Raeburn wrote:

> It works for me too. Of course, my saved .emacs.desktop already has a
> mix of display names in it; I'll have to get them in sync.

I think this won't help if you're really using multiple displays,
for example, :0.0 and :1.0.

> But of course it isn't going to address some reasonable uses of
> make-frame-on-display (including perhaps old scripts some of us may have
> lying around that invoke make-frame-on-display by way of emacsclient
> --eval). Perhaps a similar change can be made within the main Emacs
> code?

I'm afraid that we can't do anything useful on Emacs side because of libX11 bug.
If you can rebuild libX11 from git, you can try this patch; I think we should
create bug report at http://bugs.freedesktop.org...

Dmitry


lcd-core-modifiers.patch (924 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/13/2014 09:43 AM, Dmitry Antipov wrote:

> I'm afraid that we can't do anything useful on Emacs side because of libX11 bug.
> If you can rebuild libX11 from git, you can try this patch; I think we should
> create bug report at http://bugs.freedesktop.org...

BTW, can you also try to run under valgrind? When I'm trying Lucid build with:

valgrind --tool=memcheck ./src/temacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":0") (delete-frame f))'

I'm seeing a typical use-after-free error, most probably caused by libX11 bug:

==18243== Invalid read of size 1
==18243==    at 0x4A09FA4: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18243==    by 0x37D9069DE6: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==18243==    by 0x37D9050CC0: XUnregisterIMInstantiateCallback (IMWrap.c:200)
==18243==    by 0x53841E: xim_close_dpy (xterm.c:8002)
==18243==    by 0x53CFF4: x_delete_terminal (xterm.c:10465)
==18243==    by 0x517BB2: Fdelete_terminal (terminal.c:348)
==18243==    by 0x427EA6: delete_frame (frame.c:1412)
==18243==    by 0x42841C: Fdelete_frame (frame.c:1522)
==18243==    by 0x60A948: eval_sub (eval.c:2183)
==18243==    by 0x605C55: Fprogn (eval.c:463)
==18243==    by 0x607547: Flet (eval.c:971)
==18243==    by 0x60A5DF: eval_sub (eval.c:2128)
==18243==  Address 0x6435d50 is 0 bytes inside a block of size 1 free'd
==18243==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18243==    by 0x37D906002F: XSetLocaleModifiers (lcWrap.c:90)
==18243==    by 0x37DBC26AA7: _XtDefaultLanguageProc (Initialize.c:473)
==18243==    by 0x37DBC27D77: _XtDisplayInitialize (Initialize.c:824)
==18243==    by 0x37DBC1E6BA: XtOpenDisplay (Display.c:287)
==18243==    by 0x53C036: x_term_init (xterm.c:9925)
==18243==    by 0x546EB5: x_display_info_for_name (xfns.c:4356)
==18243==    by 0x53D6F6: check_x_display_info (xfns.c:170)
==18243==    by 0x543E41: Fx_create_frame (xfns.c:2910)
==18243==    by 0x60C077: Ffuncall (eval.c:2810)
==18243==    by 0x6565ED: exec_byte_code (bytecode.c:918)
==18243==    by 0x60CD07: funcall_lambda (eval.c:3044)

With libX11 trunk from git and my patch from previous e-mail, there is no such error.

Dmitry



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
Just for the record: running Motif build with the same args, i.e.

./src/emacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":0") (delete-frame f))'

produces a hard crash caused by an attempt to dereference NULL
'Display *' pointer somewhere in Motif's libXm.so library:

Program received signal SIGSEGV, Segmentation fault.
XFindContext (display=display@entry=0x0, rid=14237104, context=context@entry=-5, data=data@entry=0x7ffffffecc80) at Context.c:245
245 LockDisplay(display);
(gdb) bt
#0  XFindContext (display=display@entry=0x0, rid=14237104, context=context@entry=-5, data=data@entry=0x7ffffffecc80) at Context.c:245
#1  0x00000037da3a92d8 in _XmRCColorHook (w=w@entry=0x14bb6a0, alIn=alIn@entry=0x7ffffffed340, acPtrIn=acPtrIn@entry=0x7ffffffecd7c)
     at RCHook.c:73
#2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget@entry=0x7ffffffecec0,
     new_widget=new_widget@entry=0x14bb6a0, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1) at Create.c:231
#3  0x00000037dbc1c867 in xtCreate (name=name@entry=0xd60490 "Line Wrapping in This Buffer", class=class@entry=0x0,
     widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x157b060, default_screen=0x133b0a0,
     args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
     num_typed_args=num_typed_args@entry=0, parent_constraint_class=0x0, post_proc=post_proc@entry=0x37dbc1bef0 <widgetPostProc>)
     at Create.c:416
#4  0x00000037dbc1cc90 in _XtCreateWidget (name=name@entry=0xd60490 "Line Wrapping in This Buffer",
     widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x157b060,
     args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
     num_typed_args=num_typed_args@entry=0) at Create.c:570
#5  0x00000037dbc1cf7e in XtCreateWidget (name=name@entry=0xd60490 "Line Wrapping in This Buffer",
     widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x157b060, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1)
     at Create.c:589
#6  0x00000037da2f5a02 in create (p=p@entry=0x16c7300, name=name@entry=0xd60490 "Line Wrapping in This Buffer",
     old_al=old_al@entry=0x0, old_ac=old_ac@entry=0, type=type@entry=2, is_radio=is_radio@entry=0) at RowColumn.c:3246
#7  0x00000037da2f7cbe in XmCreatePulldownMenu (p=0x16c7300, name=0xd60490 "Line Wrapping in This Buffer", al=0x0, ac=0)
     at RowColumn.c:3485
#8  0x00000000006d07a1 in update_one_menu_entry (instance=0xe22a00, widget=0x16c88c0, val=0xd60420, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:695
#9  0x00000000006d0b40 in xm_update_menu (instance=0xe22a00, widget=0x16c7300, val=0xd56a30, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:783
#10 0x00000000006d09c8 in update_one_menu_entry (instance=0xe22a00, widget=0x171ad50, val=0xd56a30, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:726
#11 0x00000000006d0b40 in xm_update_menu (instance=0xe22a00, widget=0x156e1e0, val=0xc53ed0, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:783
#12 0x00000000006d0ec3 in xm_update_one_widget (instance=0xe22a00, widget=0x156e1e0, val=0xc53ed0, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:879
#13 0x00000000006ce0b1 in set_one_value (instance=0xe22a00, val=0xc53ed0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:534
#14 0x00000000006ce106 in update_one_widget_instance (instance=0xe22a00, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:554
#15 0x00000000006ce14c in update_all_widget_values (info=0xce4bd0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:564
#16 0x00000000006ce370 in lw_modify_all_widgets (id=2, val=0x1384670, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:618
#17 0x00000000004a5413 in set_frame_menubar (f=0x11b59e0, first_time=false, deep_p=true) at ../../trunk/src/xmenu.c:973
#18 0x000000000045c90e in update_menu_bar (f=0x11b59e0, save_match_data=0, hooks_run=1) at ../../trunk/src/xdisp.c:11818
#19 0x000000000045c552 in prepare_menu_bars () at ../../trunk/src/xdisp.c:11701
#20 0x0000000000460b72 in redisplay_internal () at ../../trunk/src/xdisp.c:13493
#21 0x000000000045f850 in redisplay () at ../../trunk/src/xdisp.c:13112
#22 0x000000000056be8f in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffffd75f, end_time=0x0)
     at ../../trunk/src/keyboard.c:2918
#23 0x000000000057a588 in read_key_sequence (keybuf=0x7fffffffd940, bufsize=30, prompt=..., dont_downcase_last=false,
     can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../trunk/src/keyboard.c:9085
#24 0x0000000000567f3d in command_loop_1 () at ../../trunk/src/keyboard.c:1439
#25 0x0000000000608f0f in internal_condition_case (bfun=0x567b7b <command_loop_1>, handlers=..., hfun=0x567351 <cmd_error>)
     at ../../trunk/src/eval.c:1349
#26 0x0000000000567819 in command_loop_2 (ignore=...) at ../../trunk/src/keyboard.c:1170
#27 0x0000000000608392 in internal_catch (tag=..., func=0x5677f6 <command_loop_2>, arg=...) at ../../trunk/src/eval.c:1113
#28 0x00000000005677cd in command_loop () at ../../trunk/src/keyboard.c:1149
#29 0x0000000000566e7d in recursive_edit_1 () at ../../trunk/src/keyboard.c:770
#30 0x000000000056704d in Frecursive_edit () at ../../trunk/src/keyboard.c:841
#31 0x0000000000564f54 in main (argc=4, argv=0x7fffffffddc8) at ../../trunk/src/emacs.c:1656

Dmitry




Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Eli Zaretskii
> Date: Sun, 13 Jul 2014 14:56:26 +0400
> From: Dmitry Antipov <[hidden email]>
> Cc: Ken Raeburn <[hidden email]>
>
> Just for the record: running Motif build with the same args, i.e.
>
> ./src/emacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":0") (delete-frame f))'
>
> produces a hard crash caused by an attempt to dereference NULL
> 'Display *' pointer somewhere in Motif's libXm.so library:
>
> Program received signal SIGSEGV, Segmentation fault.
> XFindContext (display=display@entry=0x0, rid=14237104, context=context@entry=-5, data=data@entry=0x7ffffffecc80) at Context.c:245
> 245 LockDisplay(display);
> (gdb) bt
> #0  XFindContext (display=display@entry=0x0, rid=14237104, context=context@entry=-5, data=data@entry=0x7ffffffecc80) at Context.c:245
> #1  0x00000037da3a92d8 in _XmRCColorHook (w=w@entry=0x14bb6a0, alIn=alIn@entry=0x7ffffffed340, acPtrIn=acPtrIn@entry=0x7ffffffecd7c)
>      at RCHook.c:73
> #2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget@entry=0x7ffffffecec0,
>      new_widget=new_widget@entry=0x14bb6a0, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1) at Create.c:231
> #3  0x00000037dbc1c867 in xtCreate (name=name@entry=0xd60490 "Line Wrapping in This Buffer", class=class@entry=0x0,
>      widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x157b060, default_screen=0x133b0a0,
>      args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
>      num_typed_args=num_typed_args@entry=0, parent_constraint_class=0x0, post_proc=post_proc@entry=0x37dbc1bef0 <widgetPostProc>)
>      at Create.c:416
> #4  0x00000037dbc1cc90 in _XtCreateWidget (name=name@entry=0xd60490 "Line Wrapping in This Buffer",
>      widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x157b060,
>      args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
>      num_typed_args=num_typed_args@entry=0) at Create.c:570
> #5  0x00000037dbc1cf7e in XtCreateWidget (name=name@entry=0xd60490 "Line Wrapping in This Buffer",
>      widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x157b060, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1)
>      at Create.c:589
> #6  0x00000037da2f5a02 in create (p=p@entry=0x16c7300, name=name@entry=0xd60490 "Line Wrapping in This Buffer",
>      old_al=old_al@entry=0x0, old_ac=old_ac@entry=0, type=type@entry=2, is_radio=is_radio@entry=0) at RowColumn.c:3246
> #7  0x00000037da2f7cbe in XmCreatePulldownMenu (p=0x16c7300, name=0xd60490 "Line Wrapping in This Buffer", al=0x0, ac=0)
>      at RowColumn.c:3485
> #8  0x00000000006d07a1 in update_one_menu_entry (instance=0xe22a00, widget=0x16c88c0, val=0xd60420, deep_p=1 '\001')
>      at ../../trunk/lwlib/lwlib-Xm.c:695
> #9  0x00000000006d0b40 in xm_update_menu (instance=0xe22a00, widget=0x16c7300, val=0xd56a30, deep_p=1 '\001')
>      at ../../trunk/lwlib/lwlib-Xm.c:783
> #10 0x00000000006d09c8 in update_one_menu_entry (instance=0xe22a00, widget=0x171ad50, val=0xd56a30, deep_p=1 '\001')
>      at ../../trunk/lwlib/lwlib-Xm.c:726
> #11 0x00000000006d0b40 in xm_update_menu (instance=0xe22a00, widget=0x156e1e0, val=0xc53ed0, deep_p=1 '\001')
>      at ../../trunk/lwlib/lwlib-Xm.c:783
> #12 0x00000000006d0ec3 in xm_update_one_widget (instance=0xe22a00, widget=0x156e1e0, val=0xc53ed0, deep_p=1 '\001')
>      at ../../trunk/lwlib/lwlib-Xm.c:879
> #13 0x00000000006ce0b1 in set_one_value (instance=0xe22a00, val=0xc53ed0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:534
> #14 0x00000000006ce106 in update_one_widget_instance (instance=0xe22a00, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:554
> #15 0x00000000006ce14c in update_all_widget_values (info=0xce4bd0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:564
> #16 0x00000000006ce370 in lw_modify_all_widgets (id=2, val=0x1384670, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:618
> #17 0x00000000004a5413 in set_frame_menubar (f=0x11b59e0, first_time=false, deep_p=true) at ../../trunk/src/xmenu.c:973
> #18 0x000000000045c90e in update_menu_bar (f=0x11b59e0, save_match_data=0, hooks_run=1) at ../../trunk/src/xdisp.c:11818
> #19 0x000000000045c552 in prepare_menu_bars () at ../../trunk/src/xdisp.c:11701

Does it help to avoid calling update_menu_bar for frames that don't
pass the FRAME_LIVE_P test?



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/13/2014 07:04 PM, Eli Zaretskii wrote:

> Does it help to avoid calling update_menu_bar for frames that don't
> pass the FRAME_LIVE_P test?

If you mean just this:

=== modified file 'src/xdisp.c'
--- src/xdisp.c 2014-07-12 17:53:29 +0000
+++ src/xdisp.c 2014-07-13 15:32:01 +0000
@@ -11698,7 +11698,8 @@
     }

   GCPRO1 (tail);
-  menu_bar_hooks_run = update_menu_bar (f, 0, menu_bar_hooks_run);
+  if (FRAME_LIVE_P (f))
+    menu_bar_hooks_run = update_menu_bar (f, 0, menu_bar_hooks_run);
  #ifdef HAVE_WINDOW_SYSTEM
   update_tool_bar (f, 0);
  #endif

then no, at least for Ken's test case.

Dmitry




Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Eli Zaretskii
> Date: Sun, 13 Jul 2014 19:54:15 +0400
> From: Dmitry Antipov <[hidden email]>
> CC: [hidden email], [hidden email]
>
> On 07/13/2014 07:04 PM, Eli Zaretskii wrote:
>
> > Does it help to avoid calling update_menu_bar for frames that don't
> > pass the FRAME_LIVE_P test?
>
> If you mean just this:
>
> === modified file 'src/xdisp.c'
> --- src/xdisp.c 2014-07-12 17:53:29 +0000
> +++ src/xdisp.c 2014-07-13 15:32:01 +0000
> @@ -11698,7 +11698,8 @@
>      }
>
>    GCPRO1 (tail);
> -  menu_bar_hooks_run = update_menu_bar (f, 0, menu_bar_hooks_run);
> +  if (FRAME_LIVE_P (f))
> +    menu_bar_hooks_run = update_menu_bar (f, 0, menu_bar_hooks_run);
>   #ifdef HAVE_WINDOW_SYSTEM
>    update_tool_bar (f, 0);
>   #endif
>
> then no, at least for Ken's test case.

No, I meant to skip the entire loop for non-live frames, like we do
for tooltip frames.

If this doesn't fix the crash, then please show the backtrace, because
the previous one started with the update_menu_bar call.  If it is
called for a frame other than the one just deleted, then what exactly
is the reason for the crash?  Why is the frame's display structure
NULL?



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/13/2014 08:35 PM, Eli Zaretskii wrote:

> If this doesn't fix the crash, then please show the backtrace, because
> the previous one started with the update_menu_bar call.

The backtrace at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17975#20
has 32 frames started from main.  For the record, this is another one:

#0  XFindContext (display=display@entry=0x0, rid=12681952, context=context@entry=-5, data=data@entry=0x7ffffffecc80) at Context.c:245
#1  0x00000037da3a92d8 in _XmRCColorHook (w=w@entry=0x143d0c0, alIn=alIn@entry=0x7ffffffed340, acPtrIn=acPtrIn@entry=0x7ffffffecd7c)
     at RCHook.c:73
#2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget@entry=0x7ffffffecec0,
     new_widget=new_widget@entry=0x143d0c0, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1) at Create.c:231
#3  0x00000037dbc1c867 in xtCreate (name=name@entry=0xd62ce0 "Line Wrapping in This Buffer", class=class@entry=0x0,
     widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x1535ce0, default_screen=0x133b220,
     args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
     num_typed_args=num_typed_args@entry=0, parent_constraint_class=0x0, post_proc=post_proc@entry=0x37dbc1bef0 <widgetPostProc>)
     at Create.c:416
#4  0x00000037dbc1cc90 in _XtCreateWidget (name=name@entry=0xd62ce0 "Line Wrapping in This Buffer",
     widget_class=widget_class@entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent@entry=0x1535ce0,
     args=args@entry=0x7ffffffed340, num_args=num_args@entry=1, typed_args=typed_args@entry=0x0,
     num_typed_args=num_typed_args@entry=0) at Create.c:570
#5  0x00000037dbc1cf7e in XtCreateWidget (name=name@entry=0xd62ce0 "Line Wrapping in This Buffer",
     widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x1535ce0, args=args@entry=0x7ffffffed340, num_args=num_args@entry=1)
     at Create.c:589
#6  0x00000037da2f5a02 in create (p=p@entry=0x1550760, name=name@entry=0xd62ce0 "Line Wrapping in This Buffer",
     old_al=old_al@entry=0x0, old_ac=old_ac@entry=0, type=type@entry=2, is_radio=is_radio@entry=0) at RowColumn.c:3246
#7  0x00000037da2f7cbe in XmCreatePulldownMenu (p=0x1550760, name=0xd62ce0 "Line Wrapping in This Buffer", al=0x0, ac=0)
     at RowColumn.c:3485
#8  0x00000000006d07b6 in update_one_menu_entry (instance=0xbf12a0, widget=0x1551ba0, val=0xd62c70, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:695
#9  0x00000000006d0b55 in xm_update_menu (instance=0xbf12a0, widget=0x1550760, val=0xd62a50, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:783
#10 0x00000000006d09dd in update_one_menu_entry (instance=0xbf12a0, widget=0x171bbf0, val=0xd62a50, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:726
#11 0x00000000006d0b55 in xm_update_menu (instance=0xbf12a0, widget=0x150db10, val=0xc009a0, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:783
#12 0x00000000006d0ed8 in xm_update_one_widget (instance=0xbf12a0, widget=0x150db10, val=0xc009a0, deep_p=1 '\001')
     at ../../trunk/lwlib/lwlib-Xm.c:879
#13 0x00000000006ce0c6 in set_one_value (instance=0xbf12a0, val=0xc009a0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:534
#14 0x00000000006ce11b in update_one_widget_instance (instance=0xbf12a0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:554
#15 0x00000000006ce161 in update_all_widget_values (info=0x13532a0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:564
#16 0x00000000006ce385 in lw_modify_all_widgets (id=2, val=0x1384ff0, deep_p=1 '\001') at ../../trunk/lwlib/lwlib.c:618
#17 0x00000000004a5428 in set_frame_menubar (f=0x11b49d0, first_time=false, deep_p=true) at ../../trunk/src/xmenu.c:973
#18 0x000000000045c923 in update_menu_bar (f=0x11b49d0, save_match_data=0, hooks_run=1) at ../../trunk/src/xdisp.c:11822
#19 0x000000000045c567 in prepare_menu_bars () at ../../trunk/src/xdisp.c:11705
#20 0x0000000000460b87 in redisplay_internal () at ../../trunk/src/xdisp.c:13497
#21 0x000000000045f865 in redisplay () at ../../trunk/src/xdisp.c:13116
#22 0x000000000056af8a in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffffd75f, end_time=0x0)
     at ../../trunk/src/keyboard.c:2561
#23 0x000000000057a59d in read_key_sequence (keybuf=0x7fffffffd940, bufsize=30, prompt=..., dont_downcase_last=false,
     can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../trunk/src/keyboard.c:9085
#24 0x0000000000567f52 in command_loop_1 () at ../../trunk/src/keyboard.c:1439
#25 0x0000000000608f24 in internal_condition_case (bfun=0x567b90 <command_loop_1>, handlers=..., hfun=0x567366 <cmd_error>)
     at ../../trunk/src/eval.c:1349
#26 0x000000000056782e in command_loop_2 (ignore=...) at ../../trunk/src/keyboard.c:1170
#27 0x00000000006083a7 in internal_catch (tag=..., func=0x56780b <command_loop_2>, arg=...) at ../../trunk/src/eval.c:1113
#28 0x00000000005677e2 in command_loop () at ../../trunk/src/keyboard.c:1149
#29 0x0000000000566e92 in recursive_edit_1 () at ../../trunk/src/keyboard.c:770
#30 0x0000000000567062 in Frecursive_edit () at ../../trunk/src/keyboard.c:841
#31 0x0000000000564f69 in main (argc=4, argv=0x7fffffffddc8) at ../../trunk/src/emacs.c:1656

> If it is
> called for a frame other than the one just deleted, then what exactly
> is the reason for the crash?  Why is the frame's display structure
> NULL?

I don't know what "the frame's display structure" is.

If you mean F->output_data.x->display_info->display, then it looks
correct.  For the crash listed above (frame pointer noticed at #18):

(gdb) p ((struct frame *)0x11b49d0)->output_data.x->display_info
$1 = (struct x_display_info *) 0xd834a0
(gdb) p ((struct frame *)0x11b49d0)->output_data.x->display_info->display
$2 = (Display *) 0xc182e0

And the frame is definitely live:

(gdb) p ((struct frame *)0x11b49d0)->terminal
$3 = (struct terminal *) 0x11b3c28

Dmitry




Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Eli Zaretskii
> Date: Sun, 13 Jul 2014 22:01:04 +0400
> From: Dmitry Antipov <[hidden email]>
> CC: [hidden email], [hidden email]
>
> On 07/13/2014 08:35 PM, Eli Zaretskii wrote:
>
> > If this doesn't fix the crash, then please show the backtrace, because
> > the previous one started with the update_menu_bar call.
>
> The backtrace at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17975#20
> has 32 frames started from main.  For the record, this is another one:

It still includes the call to update_menu_bar.  So which frame is it
that is passed to update_menu_bar -- the one you deleted or the one
just created by make-frame-on-display?



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Ken Raeburn-5
In reply to this post by Dmitry Antipov-3

On Jul 13, 2014, at 01:43, Dmitry Antipov <[hidden email]> wrote:

> On 07/12/2014 01:22 AM, Ken Raeburn wrote:
>
>> It works for me too. Of course, my saved .emacs.desktop already has a
>> mix of display names in it; I'll have to get them in sync.
>
> I think this won't help if you're really using multiple displays,
> for example, :0.0 and :1.0.

I meant a mix of :0 and :0.0 forms had been saved.

>
>> But of course it isn't going to address some reasonable uses of
>> make-frame-on-display (including perhaps old scripts some of us may have
>> lying around that invoke make-frame-on-display by way of emacsclient
>> --eval). Perhaps a similar change can be made within the main Emacs
>> code?
>
> I'm afraid that we can't do anything useful on Emacs side because of libX11 bug.

Would it not be enough to do a similar canonicalization of $DISPLAY and the make-frame-on-display argument, if that was enough in emacsclient?

> If you can rebuild libX11 from git, you can try this patch; I think we should
> create bug report at http://bugs.freedesktop.org...

I don't think it would be practical for me to run a patched X11 at work. I was going to run a test at home, but my home GNU/Linux setup (Debian "wheezy" distro) seems to have a newer X11 package (1.5.0, with patches including ximcp/imLcPrs.c and imTrX.c but not imInsClbk.c) than the one at work (Ubuntu "precise" distro, 1.4.99.1 with patches), and I haven't been able to reproduce the problem yet.

I tried running under valgrind (on the Ubuntu system where I can reproduce the problem, similar invocation except for using localhost:10 and localhost:10.0 because I'm logged in remotely) and I got an invalid-read error as well, though the location where the memory was already freed is in Emacs, not in X11 (though perhaps that just means X11 freed it while Emacs kept a dangling reference, then Emacs allocated the same buffer pointer and freed it again):

==5812== Invalid read of size 1
==5812==    at 0x4C2CB64: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5812==    by 0x699F2E9: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==5812==    by 0x69861B4: XUnregisterIMInstantiateCallback (IMWrap.c:200)
==5812==    by 0x4EA5F4: x_delete_terminal (xterm.c:8003)
==5812==    by 0x4DDFE1: Fdelete_terminal (terminal.c:348)
==5812==    by 0x423755: delete_frame (frame.c:1399)
==5812==    by 0x5A08DD: eval_sub (eval.c:2188)
==5812==    by 0x5A0CE4: Fprogn (eval.c:468)
==5812==    by 0x5A4846: Flet (eval.c:976)
==5812==    by 0x5A06B6: eval_sub (eval.c:2133)
==5812==    by 0x5A3310: Feval (eval.c:2003)
==5812==    by 0x5A16FD: Ffuncall (eval.c:2818)
==5812==  Address 0xed139b0 is 0 bytes inside a block of size 10 free'd
==5812==    at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5812==    by 0x581861: xrealloc (alloc.c:717)
==5812==    by 0x4B187A: alloc_destination (coding.c:1060)
==5812==    by 0x4B3F98: encode_coding_utf_8 (coding.c:1546)
==5812==    by 0x4BEB2A: encode_coding_object (coding.c:7783)
==5812==    by 0x4C0643: code_convert_string (coding.c:9470)
==5812==    by 0x47E376: digest_single_submenu (menu.c:784)
==5812==    by 0x47FB2B: set_frame_menubar (xmenu.c:901)
==5812==    by 0x503C80: Fx_create_frame (xfns.c:3192)
==5812==    by 0x5A1731: Ffuncall (eval.c:2815)
==5812==    by 0x5E055C: exec_byte_code (bytecode.c:916)
==5812==    by 0x5A0F91: funcall_lambda (eval.c:3049)
==5812==

xterm.c:8007: Emacs fatal error: assertion failed: ret == True
Fatal error 6: Aborted

Ken


Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
In reply to this post by Eli Zaretskii
On 07/13/2014 10:28 PM, Eli Zaretskii wrote:

> It still includes the call to update_menu_bar.  So which frame is it
> that is passed to update_menu_bar -- the one you deleted or the one
> just created by make-frame-on-display?

The just created one.

Dmitry




Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
In reply to this post by Ken Raeburn-5
On 07/14/2014 09:13 AM, Ken Raeburn wrote:

> Would it not be enough to do a similar canonicalization of $DISPLAY
> and the make-frame-on-display argument, if that was enough in emacsclient?

Probably no - the following example also crashes:

./src/emacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":1.0") (delete-frame f))'

where :1.0 is Xnest running on the same machine.

> I don't think it would be practical for me to run a patched X11 at work. I was going to run a test at home,
> but my home GNU/Linux setup (Debian "wheezy" distro) seems to have a newer X11 package (1.5.0, with patches
> including ximcp/imLcPrs.c and imTrX.c but not imInsClbk.c) than the one at work (Ubuntu "precise" distro,
> 1.4.99.1 with patches), and I haven't been able to reproduce the problem yet.

I tried both stock Fedora 20 libX11-1.6.1 and 1.6.2 recompiled from rawhide,
and was able to reproduce with both.

This mess raises up an old question: should Emacs treat localhost:0/unix:0/:0.0/:0 etc.
like the same display and has the only connection for all of them? It was discussed a long
time ago, at least at http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html.

Dmitry




Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Jan D.-2
Hi.

14 jul 2014 kl. 09:23 skrev Dmitry Antipov <[hidden email]>:

> This mess raises up an old question: should Emacs treat localhost:0/unix:0/:0.0/:0 etc.
> like the same display and has the only connection for all of them? It was discussed a long
> time ago, at least at http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html.

unix:0 and :0 may be talking to the same X server, but they may use different transports.
So in some sense they are not "the same".

        Jan D.





Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Dmitry Antipov-3
On 07/14/2014 12:10 PM, Jan Djärv wrote:

> unix:0 and :0 may be talking to the same X server, but they may use different transports.
> So in some sense they are not "the same".

Heh, IP and name resolving makes an even more trouble - 127.0.0.1:0, locahost:0,
myhost:0, [external-IP]:0 and myhost.mydomain.com:0 may be talking to the same
X server by using the same transport.

Dmitry





Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Ken Raeburn-5
Also -- lest we make any incorrect assumptions about the display names -- some code on Mac OS X sets the $DISPLAY string for the local display to the full path to a unix-domain socket, the name of which just happens to end with ":0". I suspect it's a launchd thing, where connecting triggers launchd to start up the X server and pass data through. But, an X11-configured Emacs on Mac OS X, run from a Terminal window, may have to deal with it, so we can't assume it's a host name.​

I'm not sure the different transport matters much, so long as when the user asks us to connect to the local server, we connect to the local server. But I don't want to rehash that discussion here, and it doesn't help me much if using two different displays will trigger the same problem.
Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Ken Raeburn-5
In reply to this post by Ken Raeburn-5

I don't see it listed in the bug report here, so to put it on the
record: Dmitry did file a bug report upstream on 2014-07-14.  It can be
found at https://bugs.freedesktop.org/show_bug.cgi?id=81338 .  It seems
to have gotten no attention since.  (Though with no test case smaller
than Emacs, it might seem a bit daunting to non-Emacs-using developers.)

It will surprise no one that the emacs-25 pretests can still trigger the
crash.



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Lars Ingebrigtsen
In reply to this post by Dmitry Antipov-3
Dmitry Antipov <[hidden email]> writes:

> ==18243==  Address 0x6435d50 is 0 bytes inside a block of size 1 free'd
> ==18243== at 0x4A07577: free (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==18243==    by 0x37D906002F: XSetLocaleModifiers (lcWrap.c:90)
> ==18243==    by 0x37DBC26AA7: _XtDefaultLanguageProc (Initialize.c:473)

(This was six years ago.)

I tried this with Emacs 28 now (on Debian bullseye), and valgrind did
not output this warning.  (This is with a lucid build.)  However,
looking at the x11 bug tracker, there doesn't seem to have been any
progress there:

  https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/36

So are you still seeing this problem?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

Lars Ingebrigtsen
In reply to this post by Dmitry Antipov-3
Dmitry Antipov <[hidden email]> writes:

> Just for the record: running Motif build with the same args, i.e.
>
> ./src/emacs -Q --eval '(let ((f (selected-frame)))
> (make-frame-on-display ":0") (delete-frame f))'
>
> produces a hard crash caused by an attempt to dereference NULL
> 'Display *' pointer somewhere in Motif's libXm.so library:
>
> Program received signal SIGSEGV, Segmentation fault.
> XFindContext (display=display@entry=0x0, rid=14237104,
> context=context@entry=-5, data=data@entry=0x7ffffffecc80) at

I tried this on Debian bullseye (and Emacs 28) now, and it did not
segfault.  Are you still able to reproduce this bug?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



12