* 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)
@ 2014-07-08 19:59 Ken Raeburn
2014-07-09 5:37 ` Dmitry Antipov
2016-04-13 18:19 ` Ken Raeburn
0 siblings, 2 replies; 23+ messages in thread
From: Ken Raeburn @ 2014-07-08 19:59 UTC (permalink / raw)
To: 17975
(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))
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-08 19:59 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
@ 2014-07-09 5:37 ` Dmitry Antipov
2014-07-11 21:22 ` Ken Raeburn
2016-04-13 18:19 ` Ken Raeburn
1 sibling, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-09 5:37 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 17975
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
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
[-- Attachment #2: bug17975.patch --]
[-- Type: text/x-patch, Size: 1432 bytes --]
=== modified file 'lib-src/emacsclient.c'
--- lib-src/emacsclient.c 2014-06-17 16:09:19 +0000
+++ lib-src/emacsclient.c 2014-07-09 05:30:11 +0000
@@ -82,6 +82,8 @@
#include <signal.h>
#include <errno.h>
+#include <intprops.h>
+
#ifndef VERSION
#define VERSION "unspecified"
#endif
@@ -1517,6 +1519,31 @@
#endif /* WINDOWSNT */
}
+/* Return the canonical HOST:SEQUENCE.SCREEN name of DISPLAY.
+ For some weird reason, this is important for XIM (Bug#17975). */
+
+static char *
+x_canonical_display (char *display)
+{
+ char host[256]; /* Max. FQDN length is 255. */
+ int sequence, screen;
+
+ if (sscanf (display, "%s:%d.%d", host, &sequence, &screen) == 3)
+ /* canonical */ ;
+ else if (sscanf (display, "%d:%d", &sequence, &screen) == 2
+ || sscanf (display, ":%d:%d", &sequence, &screen) == 2)
+ {
+ display = xmalloc (4 + INT_BUFSIZE_BOUND (int) * 2 + 3);
+ sprintf (display, "unix:%d.%d", sequence, screen);
+ }
+ else if (sscanf (display, ":%d", &sequence) == 1)
+ {
+ display = xmalloc (4 + INT_BUFSIZE_BOUND (int) + 4);
+ sprintf (display, "unix:%d.0", sequence);
+ }
+ return display;
+}
+
int
main (int argc, char **argv)
{
@@ -1585,6 +1612,9 @@
w32_give_focus ();
#endif /* HAVE_NTGUI */
+ if (display)
+ display = x_canonical_display ((char *) display);
+
/* Send over our environment and current directory. */
if (!current_frame)
{
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-09 5:37 ` Dmitry Antipov
@ 2014-07-11 21:22 ` Ken Raeburn
2014-07-13 5:43 ` Dmitry Antipov
0 siblings, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2014-07-11 21:22 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 17975
Dmitry Antipov <dmantipov@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-11 21:22 ` Ken Raeburn
@ 2014-07-13 5:43 ` Dmitry Antipov
2014-07-13 10:49 ` Dmitry Antipov
2014-07-14 5:13 ` Ken Raeburn
0 siblings, 2 replies; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-13 5:43 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 17975
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
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
[-- Attachment #2: lcd-core-modifiers.patch --]
[-- Type: text/x-patch, Size: 895 bytes --]
diff --git a/modules/im/ximcp/imInsClbk.c b/modules/im/ximcp/imInsClbk.c
index d5527e0..97ed616 100644
--- a/modules/im/ximcp/imInsClbk.c
+++ b/modules/im/ximcp/imInsClbk.c
@@ -175,7 +175,14 @@ _XimRegisterIMInstantiateCallback(
icb->display = display;
icb->lcd = lcd;
MakeLocale( lcd, icb->name );
- icb->modifiers = lcd->core->modifiers; /* XXXXX */
+ if ( lcd->core->modifiers ) {
+ icb->modifiers = strdup( lcd->core->modifiers ); /* XXXXX */
+ if ( icb->modifiers == NULL ) {
+ Xfree( icb );
+ return( False );
+ }
+ } else
+ icb->modifiers = NULL;
icb->rdb = rdb;
icb->res_name = res_name;
icb->res_class = res_class;
@@ -258,6 +265,8 @@ _XimUnRegisterIMInstantiateCallback(
else
picb->next = icb->next;
_XCloseLC( icb->lcd );
+ if( icb->modifiers )
+ free( icb->modifiers );
XFree( icb );
}
return( True );
^ permalink raw reply related [flat|nested] 23+ messages in thread
* 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)
2014-07-13 5:43 ` Dmitry Antipov
@ 2014-07-13 10:49 ` Dmitry Antipov
2014-07-13 10:56 ` Dmitry Antipov
2020-09-09 11:28 ` Lars Ingebrigtsen
2014-07-14 5:13 ` Ken Raeburn
1 sibling, 2 replies; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-13 10:49 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 10:49 ` Dmitry Antipov
@ 2014-07-13 10:56 ` Dmitry Antipov
2014-07-13 15:04 ` Eli Zaretskii
2020-09-09 11:35 ` Lars Ingebrigtsen
2020-09-09 11:28 ` Lars Ingebrigtsen
1 sibling, 2 replies; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-13 10:56 UTC (permalink / raw)
To: 17975; +Cc: Ken Raeburn
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 10:56 ` Dmitry Antipov
@ 2014-07-13 15:04 ` Eli Zaretskii
2014-07-13 15:54 ` Dmitry Antipov
2020-09-09 11:35 ` Lars Ingebrigtsen
1 sibling, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-07-13 15:04 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: raeburn, 17975
> Date: Sun, 13 Jul 2014 14:56:26 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: Ken Raeburn <raeburn@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@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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 15:04 ` Eli Zaretskii
@ 2014-07-13 15:54 ` Dmitry Antipov
2014-07-13 16:35 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-13 15:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: raeburn, 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 15:54 ` Dmitry Antipov
@ 2014-07-13 16:35 ` Eli Zaretskii
2014-07-13 18:01 ` Dmitry Antipov
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-07-13 16:35 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: raeburn, 17975
> Date: Sun, 13 Jul 2014 19:54:15 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: raeburn@permabit.com, 17975@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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 16:35 ` Eli Zaretskii
@ 2014-07-13 18:01 ` Dmitry Antipov
2014-07-13 18:28 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-13 18:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: raeburn, 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 18:01 ` Dmitry Antipov
@ 2014-07-13 18:28 ` Eli Zaretskii
2014-07-14 5:20 ` Dmitry Antipov
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-07-13 18:28 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: raeburn, 17975
> Date: Sun, 13 Jul 2014 22:01:04 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: raeburn@permabit.com, 17975@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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 5:43 ` Dmitry Antipov
2014-07-13 10:49 ` Dmitry Antipov
@ 2014-07-14 5:13 ` Ken Raeburn
2014-07-14 7:23 ` Dmitry Antipov
1 sibling, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2014-07-14 5:13 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 17975
On Jul 13, 2014, at 01:43, Dmitry Antipov <dmantipov@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 18:28 ` Eli Zaretskii
@ 2014-07-14 5:20 ` Dmitry Antipov
0 siblings, 0 replies; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-14 5:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: raeburn, 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-14 5:13 ` Ken Raeburn
@ 2014-07-14 7:23 ` Dmitry Antipov
2014-07-14 8:10 ` Jan Djärv
0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-14 7:23 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-14 7:23 ` Dmitry Antipov
@ 2014-07-14 8:10 ` Jan Djärv
2014-07-14 10:19 ` Dmitry Antipov
0 siblings, 1 reply; 23+ messages in thread
From: Jan Djärv @ 2014-07-14 8:10 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Ken Raeburn, 17975
Hi.
14 jul 2014 kl. 09:23 skrev Dmitry Antipov <dmantipov@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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-14 8:10 ` Jan Djärv
@ 2014-07-14 10:19 ` Dmitry Antipov
2014-07-14 18:58 ` Ken Raeburn
0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2014-07-14 10:19 UTC (permalink / raw)
To: Jan Djärv; +Cc: Ken Raeburn, 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-14 10:19 ` Dmitry Antipov
@ 2014-07-14 18:58 ` Ken Raeburn
0 siblings, 0 replies; 23+ messages in thread
From: Ken Raeburn @ 2014-07-14 18:58 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 17975
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 857 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-08 19:59 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
2014-07-09 5:37 ` Dmitry Antipov
@ 2016-04-13 18:19 ` Ken Raeburn
1 sibling, 0 replies; 23+ messages in thread
From: Ken Raeburn @ 2016-04-13 18:19 UTC (permalink / raw)
To: 17975
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 10:49 ` Dmitry Antipov
2014-07-13 10:56 ` Dmitry Antipov
@ 2020-09-09 11:28 ` Lars Ingebrigtsen
2020-09-11 10:11 ` Dmitry Antipov
1 sibling, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-09 11:28 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Ken Raeburn, 17975
Dmitry Antipov <dmantipov@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2014-07-13 10:56 ` Dmitry Antipov
2014-07-13 15:04 ` Eli Zaretskii
@ 2020-09-09 11:35 ` Lars Ingebrigtsen
1 sibling, 0 replies; 23+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-09 11:35 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Ken Raeburn, 17975
Dmitry Antipov <dmantipov@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@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2020-09-09 11:28 ` Lars Ingebrigtsen
@ 2020-09-11 10:11 ` Dmitry Antipov
2020-09-11 12:54 ` Lars Ingebrigtsen
0 siblings, 1 reply; 23+ messages in thread
From: Dmitry Antipov @ 2020-09-11 10:11 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Ken Raeburn, 17975
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2020-09-11 10:11 ` Dmitry Antipov
@ 2020-09-11 12:54 ` Lars Ingebrigtsen
2020-09-11 13:01 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-11 12:54 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Ken Raeburn, 17975
Dmitry Antipov <dmantipov@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
^ permalink raw reply [flat|nested] 23+ messages in thread
* 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)
2020-09-11 12:54 ` Lars Ingebrigtsen
@ 2020-09-11 13:01 ` Eli Zaretskii
0 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2020-09-11 13:01 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: raeburn, 17975, dmantipov
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 11 Sep 2020 14:54:25 +0200
> Cc: Ken Raeburn <raeburn@permabit.com>, 17975@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.
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-09-11 13:01 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-08 19:59 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
2014-07-09 5:37 ` Dmitry Antipov
2014-07-11 21:22 ` Ken Raeburn
2014-07-13 5:43 ` Dmitry Antipov
2014-07-13 10:49 ` Dmitry Antipov
2014-07-13 10:56 ` Dmitry Antipov
2014-07-13 15:04 ` Eli Zaretskii
2014-07-13 15:54 ` Dmitry Antipov
2014-07-13 16:35 ` Eli Zaretskii
2014-07-13 18:01 ` Dmitry Antipov
2014-07-13 18:28 ` Eli Zaretskii
2014-07-14 5:20 ` Dmitry Antipov
2020-09-09 11:35 ` Lars Ingebrigtsen
2020-09-09 11:28 ` Lars Ingebrigtsen
2020-09-11 10:11 ` Dmitry Antipov
2020-09-11 12:54 ` Lars Ingebrigtsen
2020-09-11 13:01 ` Eli Zaretskii
2014-07-14 5:13 ` Ken Raeburn
2014-07-14 7:23 ` Dmitry Antipov
2014-07-14 8:10 ` Jan Djärv
2014-07-14 10:19 ` Dmitry Antipov
2014-07-14 18:58 ` Ken Raeburn
2016-04-13 18:19 ` Ken Raeburn
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).