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

Previous Next

Package: emacs;

Reported by: Ken Raeburn <raeburn <at> permabit.com>

Date: Wed, 9 Jul 2014 01:57:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.3.92

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Wed, 09 Jul 2014 01:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ken Raeburn <raeburn <at> permabit.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 09 Jul 2014 01:57:02 GMT) Full text and rfc822 format available.

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.92;
 assertion failure deleting frames with varying names for the same
 display (and, using multiple X11 connections in that case too)
Date: Tue, 08 Jul 2014 15:59:42 -0400
(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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Wed, 09 Jul 2014 05:39:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Wed, 09 Jul 2014 09:37:49 +0400
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Fri, 11 Jul 2014 21:23:02 GMT) Full text and rfc822 format available.

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

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Fri, 11 Jul 2014 17:22:17 -0400
Dmitry Antipov <dmantipov <at> yandex.ru> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 05:44:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 09:43:32 +0400
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 10:50:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 14:49:11 +0400
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 10:57:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: 17975 <at> debbugs.gnu.org
Cc: Ken Raeburn <raeburn <at> permabit.com>
Subject: Re: 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)
Date: Sun, 13 Jul 2014 14:56:26 +0400
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 <at> entry=0x0, rid=14237104, context=context <at> entry=-5, data=data <at> entry=0x7ffffffecc80) at Context.c:245
245		LockDisplay(display);
(gdb) bt
#0  XFindContext (display=display <at> entry=0x0, rid=14237104, context=context <at> entry=-5, data=data <at> entry=0x7ffffffecc80) at Context.c:245
#1  0x00000037da3a92d8 in _XmRCColorHook (w=w <at> entry=0x14bb6a0, alIn=alIn <at> entry=0x7ffffffed340, acPtrIn=acPtrIn <at> entry=0x7ffffffecd7c)
    at RCHook.c:73
#2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget <at> entry=0x7ffffffecec0,
    new_widget=new_widget <at> entry=0x14bb6a0, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1) at Create.c:231
#3  0x00000037dbc1c867 in xtCreate (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer", class=class <at> entry=0x0,
    widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x157b060, default_screen=0x133b0a0,
    args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
    num_typed_args=num_typed_args <at> entry=0, parent_constraint_class=0x0, post_proc=post_proc <at> entry=0x37dbc1bef0 <widgetPostProc>)
    at Create.c:416
#4  0x00000037dbc1cc90 in _XtCreateWidget (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
    widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x157b060,
    args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
    num_typed_args=num_typed_args <at> entry=0) at Create.c:570
#5  0x00000037dbc1cf7e in XtCreateWidget (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
    widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x157b060, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1)
    at Create.c:589
#6  0x00000037da2f5a02 in create (p=p <at> entry=0x16c7300, name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
    old_al=old_al <at> entry=0x0, old_ac=old_ac <at> entry=0, type=type <at> entry=2, is_radio=is_radio <at> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 15:04:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 18:04:00 +0300
> Date: Sun, 13 Jul 2014 14:56:26 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> Cc: Ken Raeburn <raeburn <at> permabit.com>
> 
> 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 <at> entry=0x0, rid=14237104, context=context <at> entry=-5, data=data <at> entry=0x7ffffffecc80) at Context.c:245
> 245		LockDisplay(display);
> (gdb) bt
> #0  XFindContext (display=display <at> entry=0x0, rid=14237104, context=context <at> entry=-5, data=data <at> entry=0x7ffffffecc80) at Context.c:245
> #1  0x00000037da3a92d8 in _XmRCColorHook (w=w <at> entry=0x14bb6a0, alIn=alIn <at> entry=0x7ffffffed340, acPtrIn=acPtrIn <at> entry=0x7ffffffecd7c)
>      at RCHook.c:73
> #2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget <at> entry=0x7ffffffecec0,
>      new_widget=new_widget <at> entry=0x14bb6a0, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1) at Create.c:231
> #3  0x00000037dbc1c867 in xtCreate (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer", class=class <at> entry=0x0,
>      widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x157b060, default_screen=0x133b0a0,
>      args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
>      num_typed_args=num_typed_args <at> entry=0, parent_constraint_class=0x0, post_proc=post_proc <at> entry=0x37dbc1bef0 <widgetPostProc>)
>      at Create.c:416
> #4  0x00000037dbc1cc90 in _XtCreateWidget (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
>      widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x157b060,
>      args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
>      num_typed_args=num_typed_args <at> entry=0) at Create.c:570
> #5  0x00000037dbc1cf7e in XtCreateWidget (name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
>      widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x157b060, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1)
>      at Create.c:589
> #6  0x00000037da2f5a02 in create (p=p <at> entry=0x16c7300, name=name <at> entry=0xd60490 "Line Wrapping in This Buffer",
>      old_al=old_al <at> entry=0x0, old_ac=old_ac <at> entry=0, type=type <at> entry=2, is_radio=is_radio <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 15:55:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 19:54:15 +0400
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 16:36:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 19:35:42 +0300
> Date: Sun, 13 Jul 2014 19:54:15 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
> 
> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 18:02:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 22:01:04 +0400
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 <at> entry=0x0, rid=12681952, context=context <at> entry=-5, data=data <at> entry=0x7ffffffecc80) at Context.c:245
#1  0x00000037da3a92d8 in _XmRCColorHook (w=w <at> entry=0x143d0c0, alIn=alIn <at> entry=0x7ffffffed340, acPtrIn=acPtrIn <at> entry=0x7ffffffecd7c)
    at RCHook.c:73
#2  0x00000037dbc1bed7 in CallInitialize (class=<optimized out>, req_widget=req_widget <at> entry=0x7ffffffecec0,
    new_widget=new_widget <at> entry=0x143d0c0, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1) at Create.c:231
#3  0x00000037dbc1c867 in xtCreate (name=name <at> entry=0xd62ce0 "Line Wrapping in This Buffer", class=class <at> entry=0x0,
    widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x1535ce0, default_screen=0x133b220,
    args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
    num_typed_args=num_typed_args <at> entry=0, parent_constraint_class=0x0, post_proc=post_proc <at> entry=0x37dbc1bef0 <widgetPostProc>)
    at Create.c:416
#4  0x00000037dbc1cc90 in _XtCreateWidget (name=name <at> entry=0xd62ce0 "Line Wrapping in This Buffer",
    widget_class=widget_class <at> entry=0x37da6b8800 <xmRowColumnClassRec>, parent=parent <at> entry=0x1535ce0,
    args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1, typed_args=typed_args <at> entry=0x0,
    num_typed_args=num_typed_args <at> entry=0) at Create.c:570
#5  0x00000037dbc1cf7e in XtCreateWidget (name=name <at> entry=0xd62ce0 "Line Wrapping in This Buffer",
    widget_class=0x37da6b8800 <xmRowColumnClassRec>, parent=0x1535ce0, args=args <at> entry=0x7ffffffed340, num_args=num_args <at> entry=1)
    at Create.c:589
#6  0x00000037da2f5a02 in create (p=p <at> entry=0x1550760, name=name <at> entry=0xd62ce0 "Line Wrapping in This Buffer",
    old_al=old_al <at> entry=0x0, old_ac=old_ac <at> entry=0, type=type <at> entry=2, is_radio=is_radio <at> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Sun, 13 Jul 2014 18:29:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Sun, 13 Jul 2014 21:28:08 +0300
> Date: Sun, 13 Jul 2014 22:01:04 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
> 
> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 05:14:02 GMT) Full text and rfc822 format available.

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

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Mon, 14 Jul 2014 01:13:10 -0400
On Jul 13, 2014, at 01:43, Dmitry Antipov <dmantipov <at> yandex.ru> 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



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 05:21:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Mon, 14 Jul 2014 09:20:39 +0400
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 07:25:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Mon, 14 Jul 2014 11:23:36 +0400
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 08:12:02 GMT) Full text and rfc822 format available.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Mon, 14 Jul 2014 10:10:58 +0200
Hi.

14 jul 2014 kl. 09:23 skrev Dmitry Antipov <dmantipov <at> yandex.ru>:

> 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.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 10:20:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Mon, 14 Jul 2014 14:19:07 +0400
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






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Mon, 14 Jul 2014 18:59:02 GMT) Full text and rfc822 format available.

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

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17975 <17975 <at> debbugs.gnu.org>,
 Jan Djärv <jan.h.d <at> swipnet.se>
Subject: Re: 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)
Date: Mon, 14 Jul 2014 14:58:43 -0400
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Wed, 13 Apr 2016 18:20:01 GMT) Full text and rfc822 format available.

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

From: Ken Raeburn <raeburn <at> permabit.com>
To: 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Wed, 13 Apr 2016 14:19:10 -0400
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Wed, 09 Sep 2020 11:29:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Wed, 09 Sep 2020 13:28:36 +0200
Dmitry Antipov <dmantipov <at> yandex.ru> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Wed, 09 Sep 2020 11:36:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Wed, 09 Sep 2020 13:35:43 +0200
Dmitry Antipov <dmantipov <at> yandex.ru> 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 <at> entry=0x0, rid=14237104,
> context=context <at> entry=-5, data=data <at> 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




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 09 Sep 2020 11:37:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Fri, 11 Sep 2020 10:12:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Fri, 11 Sep 2020 13:11:45 +0300
On 9/9/20 2:28 PM, Lars Ingebrigtsen wrote:

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

No. But, to whom it may be interesting, running the following code:
 
(dotimes (n 10000)
  (let ((x (make-frame-on-display ":1.0"))
        (y (make-frame-on-display ":1.0")))
    (delete-frame x)
    (delete-frame y)))

with Xnest (which is ":1.0") successfully raises Emacs' RSS from
~30M to ~120M.

Dmitry




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Fri, 11 Sep 2020 12:55:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
Subject: Re: 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)
Date: Fri, 11 Sep 2020 14:54:25 +0200
Dmitry Antipov <dmantipov <at> yandex.ru> writes:

>> 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?
>
> No.

OK, closing this bug report.

> But, to whom it may be interesting, running the following code:
>  (dotimes (n 10000)
>   (let ((x (make-frame-on-display ":1.0"))
>         (y (make-frame-on-display ":1.0")))
>     (delete-frame x)
>     (delete-frame y)))
>
> with Xnest (which is ":1.0") successfully raises Emacs' RSS from
> ~30M to ~120M.

This sounds like it should be reported as a new bug report.

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




bug closed, send any further explanations to 17975 <at> debbugs.gnu.org and Ken Raeburn <raeburn <at> permabit.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 11 Sep 2020 12:55:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17975; Package emacs. (Fri, 11 Sep 2020 13:03:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: raeburn <at> permabit.com, 17975 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
Subject: Re: 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)
Date: Fri, 11 Sep 2020 16:01:58 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 11 Sep 2020 14:54:25 +0200
> Cc: Ken Raeburn <raeburn <at> permabit.com>, 17975 <at> debbugs.gnu.org
> 
> > But, to whom it may be interesting, running the following code:
> >  (dotimes (n 10000)
> >   (let ((x (make-frame-on-display ":1.0"))
> >         (y (make-frame-on-display ":1.0")))
> >     (delete-frame x)
> >     (delete-frame y)))
> >
> > with Xnest (which is ":1.0") successfully raises Emacs' RSS from
> > ~30M to ~120M.
> 
> This sounds like it should be reported as a new bug report.

Probably.  But since AFAIK glibc doesn't return memory to the system,
it could be a simple consequence of the glibc memory management.  The
question is how much of those 120M - 30M is marked free for further
allocations by Emacs.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 10 Oct 2020 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 252 days ago.

Previous Next


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