* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
@ 2017-12-11 15:22 Robert Marshall
2017-12-12 8:56 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-11 15:22 UTC (permalink / raw
To: 29661
I've had a number of crashes today when running exchange-point-and-mark
on editing a particular file shortly after pasting in lots of lines from another
(v large) buffer. Probably replicable but atm hard to give an exact
recipe.
I'll keep the gdb session around in case it is needed.
Looking at gdb it appears to crash in delete_frame??
Program received signal SIGSEGV, Segmentation fault.
delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
2064 struct frame *f1 = XFRAME (frame1);
(gdb) bt full
#0 delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
f = 0x1317ef0
sf = 0x1317ef0
kb = <optimized out>
frames = XIL(0)
frame1 = <optimized out>
minibuffer_selected = <optimized out>
is_tooltip_frame = <optimized out>
nochild = <optimized out>
#1 0x00000000004bbdbb in x_connection_closed (dpy=dpy@entry=0x15e9000, error_message=<optimized out>,
error_message@entry=0x7fffffffcdd0 "Connection lost to X server ':0'", ioerror=ioerror@entry=true) at xterm.c:9791
tail = XIL(0x1023733)
#2 0x00000000004bbe76 in x_io_error_quitter (display=0x15e9000) at xterm.c:9915
buf = "Connection lost to X server ':0'\000\316\377\377\377\177\000\000P\316\377\377\377\177\000\000\000\220^\001\000\000\000\000\276-q\364\377\177\000\000P\242^\001\000\000\000\000\001\000\000\000\000\000\000\000P\367^\001\000\000\000\000\240\330\240\364\377\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000p\351\261\002\000\000\000\000\213\000@\005\000\000\000\000\000\220^\001\000\000\000\000\367\237\336\367\377\177\000\000\005", '\000' <repeats 15 times>, "\340i\033\005\000\000\000\000\000}m\364\377\177\000\000\000\220^\001\000\000\000\000\000\220^\001\000\000\000\000^\357y\000\000\000\000\000\025"...
#3 0x00007ffff47154fe in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#4 0x00007ffff4712e5d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#5 0x00007ffff46f465a in XFlush () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#6 0x00000000004d732c in x_reply_selection_request (dpyinfo=<optimized out>, event=<optimized out>) at xselect.c:694
reply_base = {
type = 31,
xany = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523
},
xkey = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
root = 1,
subwindow = 324,
time = 401,
x = 122306683,
y = 0,
---Type <return> to continue, or q <return> to quit---
x_root = 0,
y_root = 500000,
state = 0,
keycode = 32767,
same_screen = 5177591
},
xbutton = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
root = 1,
subwindow = 324,
time = 401,
x = 122306683,
y = 0,
x_root = 0,
y_root = 500000,
state = 0,
button = 32767,
same_screen = 5177591
},
xmotion = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
root = 1,
subwindow = 324,
time = 401,
x = 122306683,
y = 0,
x_root = 0,
y_root = 500000,
state = 0,
is_hint = -1 '\377',
same_screen = 5177591
},
xcrossing = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
---Type <return> to continue, or q <return> to quit---
root = 1,
subwindow = 324,
time = 401,
x = 122306683,
y = 0,
x_root = 0,
y_root = 500000,
mode = 0,
detail = 32767,
same_screen = 5177591,
focus = 0,
state = 0
},
xfocus = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
mode = 1,
detail = 0
},
xexpose = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
x = 1,
y = 0,
width = 324,
height = 0,
count = 401
},
xgraphicsexpose = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
drawable = 88080523,
x = 1,
y = 0,
width = 324,
height = 0,
count = 401,
major_code = 0,
---Type <return> to continue, or q <return> to quit---
minor_code = 122306683
},
xnoexpose = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
drawable = 88080523,
major_code = 1,
minor_code = 0
},
xvisibility = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
state = 1
},
xcreatewindow = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
parent = 88080523,
window = 1,
x = 324,
y = 0,
width = 401,
height = 0,
border_width = 122306683,
override_redirect = 0
},
xdestroywindow = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1
},
xunmap = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
---Type <return> to continue, or q <return> to quit---
event = 88080523,
window = 1,
from_configure = 324
},
xmap = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1,
override_redirect = 324
},
xmaprequest = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
parent = 88080523,
window = 1
},
xreparent = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1,
parent = 324,
x = 401,
y = 0,
override_redirect = 122306683
},
xconfigure = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1,
x = 324,
y = 0,
width = 401,
height = 0,
border_width = 122306683,
above = 2147483648000000,
---Type <return> to continue, or q <return> to quit---
override_redirect = 0
},
xgravity = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1,
x = 324,
y = 0
},
xresizerequest = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
width = 1,
height = 0
},
xconfigurerequest = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
parent = 88080523,
window = 1,
x = 324,
y = 0,
width = 401,
height = 0,
border_width = 122306683,
above = 2147483648000000,
detail = 0,
value_mask = 5177591
},
xcirculate = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
event = 88080523,
window = 1,
place = 324
},
---Type <return> to continue, or q <return> to quit---
xcirculaterequest = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
parent = 88080523,
window = 1,
place = 324
},
xproperty = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
atom = 1,
time = 324,
state = 401
},
xselectionclear = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
selection = 1,
time = 324
},
xselectionrequest = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
owner = 88080523,
requestor = 1,
selection = 324,
target = 401,
property = 122306683,
time = 2147483648000000
},
xselection = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
requestor = 88080523,
---Type <return> to continue, or q <return> to quit---
selection = 1,
target = 324,
property = 401,
time = 122306683
},
xcolormap = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
colormap = 1,
new = 324,
state = 0
},
xclient = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
message_type = 1,
format = 324,
data = {
b = "\221\001\000\000\000\000\000\000{@J\a\000\000\000\000\000\000\000",
s = {401, 0, 0, 0, 16507, 1866, 0, 0, 0, 0},
l = {401, 122306683, 2147483648000000, 140733193388032, 5177591}
}
},
xmapping = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
request = 1,
first_keycode = 0,
count = 324
},
xerror = {
type = 31,
display = 0x57c7ea3,
resourceid = 140733210152784,
serial = 22974464,
error_code = 139 '\213',
request_code = 0 '\000',
---Type <return> to continue, or q <return> to quit---
minor_code = 64 '@'
},
xkeymap = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
window = 88080523,
key_vector = "\001\000\000\000\000\000\000\000D\001\000\000\000\000\000\000\221\001\000\000\000\000\000\000{@J\a\000\000\000"
},
xgeneric = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
extension = 88080523,
evtype = 0
},
xcookie = {
type = 31,
serial = 92044963,
send_event = 16764752,
display = 0x15e9000,
extension = 88080523,
evtype = 0,
cookie = 1,
data = 0x144
},
pad = {31, 92044963, 140733210152784, 22974464, 88080523, 1, 324, 401, 122306683, 2147483648000000,
140733193388032, 5177591, 0, 2147483648000000, 140733193388032, 0, 97414500, 5190006, 0, 0, 48139624,
1513004943, 92044899, 92044979}
}
window = 88080523
#7 x_handle_selection_request (event=<optimized out>) at xselect.c:832
selection = 262040
local_selection_time = 0
local_selection_data = XIL(0)
dpyinfo = 0x79ef5e
property = 22974464
success = false
#8 x_handle_selection_event (event=0x2b1e970) at xselect.c:963
No locals.
#9 0x00000000004f36e2 in process_special_events () at keyboard.c:4246
copy = {
kind = SELECTION_REQUEST_EVENT,
---Type <return> to continue, or q <return> to quit---
dpyinfo = 0x16632e0,
requestor = 88080523,
selection = 1,
target = 324,
property = 401,
time = 122306683
}
beg = 0xb87e30 <kbd_buffer+14896>
event = 0xb87e30 <kbd_buffer+14896>
#10 0x00000000004f40bd in swallow_events (do_display=<optimized out>) at keyboard.c:4264
old_timers_run = <optimized out>
#11 0x00000000005a3e20 in wait_reading_process_output (time_limit=1, nsecs=0, read_kbd=0, do_display=false,
wait_for_cell=XIL(0x1317e00), wait_proc=0x2a8f4b0, just_wait_proc=0) at process.c:5510
old_timers_run = 617
old_buffer = 0x2a8f4b0
old_window = XIL(0x5cf3845)
leave = true
process_skipped = true
nfds = 1
Available = {
fds_bits = {64, 0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = false
check_delay = 1
no_avail = false
xerrno = 11
timeout = {
tv_sec = 0,
tv_nsec = 0
}
end_time = {
tv_sec = 0,
tv_nsec = 0
}
#12 0x0000000000421112 in sit_for (timeout=make_number(50), reading=253, display_option=0) at dispnew.c:5793
sec = 202
nsec = 0
#13 0x00000000004f8c15 in read_char (commandflag=commandflag@entry=1, map=XIL(0xfffffffffffffffd),
map@entry=XIL(0x10249e3), prev_event=XIL(0), used_mouse_menu=0x0, used_mouse_menu@entry=0x7fffffffdb6b,
end_time=0x1317e00, end_time@entry=0x0) at keyboard.c:2717
tem0 = XIL(0)
buffer_size = 0
local_getcjmp = {{
---Type <return> to continue, or q <return> to quit---
__jmpbuf = {23476993, -5963633980627533669, 3, 23477216, 140737488346176, 0, 5963636584858206363,
-5963636162151628645},
__mask_was_saved = 0,
__saved_mask = {
__val = {44627125, 56832, 101300596, 19429125, 16741059, 19429125, 18249683, 19622325, 101300596, 23072208,
4217902893331710400, 9448903869477172611, 3855962269045293109, 15062352596681216, 3855962132650836675,
14394386273282803212}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
save = XIL(0x1663be0)
previous_echo_area_message = XIL(0)
also_record = XIL(0)
reread = false
recorded = false
polling_stopped_here = false
#14 0x00000000004f99ca in read_key_sequence (keybuf=keybuf@entry=0x7fffffffdc40, prompt=prompt@entry=XIL(0),
dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9150
interrupted_kboard = 0x1663be0
interrupted_frame = 0x1317ef0
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = <optimized out>
new_binding = <optimized out>
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = XIL(0x10249e3)
first_event = XIL(0)
first_unbound = 31
mock_input = 0
fkey = {
parent = XIL(0x1034243),
map = XIL(0x1034243),
start = 0,
end = 0
---Type <return> to continue, or q <return> to quit---
}
keytran = {
parent = XIL(0xc31a93),
map = XIL(0xc31a93),
start = 0,
end = 0
}
indec = {
parent = XIL(0x1034253),
map = XIL(0x1034253),
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = XIL(0)
original_uppercase = XIL(0x3ee8)
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x2a8f4b0
fake_prefixed_keys = XIL(0)
#15 0x00000000004fb4a6 in command_loop_1 () at keyboard.c:1368
cmd = <optimized out>
keybuf = {make_number(24), make_number(24), make_number(98), XIL(0x4ef405), XIL(0), XIL(0x3), XIL(0x3),
make_number(1410489), XIL(0x5ce320), XIL(0x3464ea3), XIL(0x7fffffffdd00), XIL(0x3464ea3), XIL(0xffffffff),
XIL(0x563614), XIL(0x69320), XIL(0x3464ea3), XIL(0x85ed64), XIL(0x5ce320), XIL(0x3464ea3), make_number(1296728),
XIL(0x7fffffffdd00), XIL(0), XIL(0), XIL(0x4f2697), XIL(0xfd3100), make_number(1000), XIL(0xffffffff),
make_number(1409433), XIL(0x5), XIL(0x7a10)}
i = <optimized out>
prev_modiff = 3
prev_buffer = 0x2a8f4b0
#16 0x000000000055fe67 in internal_condition_case (bfun=bfun@entry=0x4fb2a0 <command_loop_1>,
handlers=handlers@entry=XIL(0x5250), hfun=hfun@entry=0x4f2590 <cmd_error>) at eval.c:1332
val = XIL(0)
c = 0x15cf9d0
#17 0x00000000004ed3ac in command_loop_2 (ignore=ignore@entry=XIL(0)) at keyboard.c:1110
val = XIL(0)
#18 0x000000000055fdf4 in internal_catch (tag=tag@entry=XIL(0xc720), func=func@entry=0x4ed390 <command_loop_2>,
arg=arg@entry=XIL(0)) at eval.c:1097
val = XIL(0)
c = 0x15cf8b0
#19 0x00000000004ed369 in command_loop () at keyboard.c:1089
No locals.
#20 0x00000000004f2196 in recursive_edit_1 () at keyboard.c:695
val = <optimized out>
#21 0x00000000004f24b3 in Frecursive_edit () at keyboard.c:766
buffer = <optimized out>
---Type <return> to continue, or q <return> to quit---
#22 0x00000000004177de in main (argc=1, argv=0x7fffffffdfb8) at emacs.c:1711
stack_bottom_variable = 0x7fffffffde60
skip_args = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
rlim = {
rlim_cur = 10022912,
rlim_max = 18446744073709551615
}
(gdb) xbacktrace
(gdb)
In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.25)
of 2017-11-14 built on ct-lt-579
Repository revision: 13248f7444630508cfc3b78a07e8d96613af11c8
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8.9 (jessie)
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11
Important settings:
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Help
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-11 15:22 bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark Robert Marshall
@ 2017-12-12 8:56 ` martin rudalics
2017-12-12 9:49 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2017-12-12 8:56 UTC (permalink / raw
To: Robert Marshall, 29661
> Program received signal SIGSEGV, Segmentation fault.
> delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
> 2064 struct frame *f1 = XFRAME (frame1);
So it seems we always have to check Vframe_list for emptyness before
running FOR_EACH_FRAME. Funny this was never seen before ...
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-12 8:56 ` martin rudalics
@ 2017-12-12 9:49 ` Robert Marshall
2017-12-12 10:28 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-12 9:49 UTC (permalink / raw
To: martin rudalics; +Cc: 29661
martin rudalics <rudalics@gmx.at> writes:
>> Program received signal SIGSEGV, Segmentation fault.
>> delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
>> 2064 struct frame *f1 = XFRAME (frame1);
>
> So it seems we always have to check Vframe_list for emptyness before
> running FOR_EACH_FRAME. Funny this was never seen before ...
>
I can also replicate this crash on version 24.4.1 - but maybe you're
saying it's been a long term problem.
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-12 9:49 ` Robert Marshall
@ 2017-12-12 10:28 ` martin rudalics
2017-12-12 10:55 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2017-12-12 10:28 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> I can also replicate this crash on version 24.4.1 - but maybe you're
> saying it's been a long term problem.
Great (you earlier only said that it's "probably replicable"). Could
you check that Vframe_list is empty at the time FOR_EACH_FRAME is run
somewhere around line 2064 (or 2067 on current master, as I believe).
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-12 10:28 ` martin rudalics
@ 2017-12-12 10:55 ` Robert Marshall
2017-12-13 8:48 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-12 10:55 UTC (permalink / raw
To: martin rudalics; +Cc: 29661
martin rudalics <rudalics@gmx.at> writes:
>> I can also replicate this crash on version 24.4.1 - but maybe you're
>> saying it's been a long term problem.
>
> Great (you earlier only said that it's "probably replicable"). Could
> you check that Vframe_list is empty at the time FOR_EACH_FRAME is run
> somewhere around line 2064 (or 2067 on current master, as I believe).
>
> Thanks, martin
Breakpoint 3, delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2062
2062 FOR_EACH_FRAME (frames, frame1)
(gdb) p Vframe_list
$1 = XIL(0)
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
2064 struct frame *f1 = XFRAME (frame1);
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-12 10:55 ` Robert Marshall
@ 2017-12-13 8:48 ` martin rudalics
2017-12-13 10:06 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2017-12-13 8:48 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
> Breakpoint 3, delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2062
> 2062 FOR_EACH_FRAME (frames, frame1)
> (gdb) p Vframe_list
> $1 = XIL(0)
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
> 2064 struct frame *f1 = XFRAME (frame1);
Thanks. The attached patch should fix that. Please check.
But I have no idea how to proceed with the x_reply_selection_request
failure.
martin
[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 1394 bytes --]
diff --git a/src/frame.c b/src/frame.c
index 5bafbed..66d1b5c 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2058,7 +2058,7 @@ of them (the selected terminal frame) is actually displayed.
/* If we've deleted the last_nonminibuf_frame, then try to find
another one. */
- if (f == last_nonminibuf_frame)
+ if (f == last_nonminibuf_frame && !NILP (Vframe_list))
{
last_nonminibuf_frame = 0;
@@ -2076,7 +2076,7 @@ of them (the selected terminal frame) is actually displayed.
/* If there's no other frame on the same kboard, get out of
single-kboard state if we're in it for this kboard. */
- if (kb != NULL)
+ if (kb != NULL && !NILP (Vframe_list))
{
/* Some frame we found on the same kboard, or nil if there are none. */
Lisp_Object frame_on_same_kboard = Qnil;
@@ -2093,7 +2093,9 @@ of them (the selected terminal frame) is actually displayed.
/* If we've deleted this keyboard's default_minibuffer_frame, try to
find another one. Prefer minibuffer-only frames, but also notice
frames with other windows. */
- if (kb != NULL && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame)))
+ if (kb != NULL
+ && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame))
+ && !NILP (Vframe_list))
{
/* The last frame we saw with a minibuffer, minibuffer-only or not. */
Lisp_Object frame_with_minibuf = Qnil;
^ permalink raw reply related [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-13 8:48 ` martin rudalics
@ 2017-12-13 10:06 ` Robert Marshall
2017-12-13 14:01 ` Robert Marshall
2017-12-13 19:29 ` martin rudalics
0 siblings, 2 replies; 25+ messages in thread
From: Robert Marshall @ 2017-12-13 10:06 UTC (permalink / raw
To: martin rudalics; +Cc: 29661
martin rudalics <rudalics@gmx.at> writes:
>> Breakpoint 3, delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2062
>> 2062 FOR_EACH_FRAME (frames, frame1)
>> (gdb) p Vframe_list
>> $1 = XIL(0)
>> (gdb) c
>> Continuing.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2064
>> 2064 struct frame *f1 = XFRAME (frame1);
>
> Thanks. The attached patch should fix that. Please check.
>
> But I have no idea how to proceed with the x_reply_selection_request
> failure.
>
> martin
>
> diff --git a/src/frame.c b/src/frame.c
> index 5bafbed..66d1b5c 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -2058,7 +2058,7 @@ of them (the selected terminal frame) is actually displayed.
>
> /* If we've deleted the last_nonminibuf_frame, then try to find
> another one. */
> - if (f == last_nonminibuf_frame)
> + if (f == last_nonminibuf_frame && !NILP (Vframe_list))
> {
> last_nonminibuf_frame = 0;
>
> @@ -2076,7 +2076,7 @@ of them (the selected terminal frame) is actually displayed.
>
> /* If there's no other frame on the same kboard, get out of
> single-kboard state if we're in it for this kboard. */
> - if (kb != NULL)
> + if (kb != NULL && !NILP (Vframe_list))
> {
> /* Some frame we found on the same kboard, or nil if there are none. */
> Lisp_Object frame_on_same_kboard = Qnil;
> @@ -2093,7 +2093,9 @@ of them (the selected terminal frame) is actually displayed.
> /* If we've deleted this keyboard's default_minibuffer_frame, try to
> find another one. Prefer minibuffer-only frames, but also notice
> frames with other windows. */
> - if (kb != NULL && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame)))
> + if (kb != NULL
> + && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame))
> + && !NILP (Vframe_list))
> {
> /* The last frame we saw with a minibuffer, minibuffer-only or not. */
> Lisp_Object frame_with_minibuf = Qnil;
Thanks, it now no longer crashes there, but crashes elsewhere but looks
to about to terminate in a more controlled manner?
#1 check_glyph_memory () at dispnew.c:2264
tail = XIL(0)
#2 0x00000000004ecead in shut_down_emacs (sig=sig@entry=0, stuff=stuff@entry=XIL(0)) at emacs.c:2107
No locals.
#3 0x00000000004bbdeb in x_connection_closed (dpy=dpy@entry=0x15e5800, error_message=<optimized out>,
error_message@entry=0x7fffffffcda0 "Connection lost to X server ':0'", ioerror=ioerror@entry=true) at xterm.c:9806
tail = <optimized out>
#4 0x00000000004bbe96 in x_io_error_quitter (display=0x15e5800) at xterm.c:9915
buf = "Connection lost to X server ':0'\000\315\377\377\377\177\000\000 \316\377\377\377\177\000\000\000X^\001\000\000\000\000\276-q\364\377\177\000\000Pj^\001\000\000\000\000\001\000\000\000\000\000\000\000\360\274^\001\000\000\000\000\240\330\240\364\377\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\300{\355\000\000\000\000\000\363\000@\005\000\000\000\000\000X^\001\000\000\000\000\367\237\336\367\377\177\000\000\005", '\000' <repeats 15 times>, "\340\177\373\000\000\000\000\000\000}m\364\377\177\000\000\000X^\001\000\000\000\000\000X^\001\000\000\000\000t\031@\002\000\000\000\000\025"...
#5 0x00007ffff47154fe in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#6 0x00007ffff4712e5d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#7 0x00007ffff46f465a in XFlush () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#8 0x00000000004d734c in x_reply_selection_request (dpyinfo=<optimized out>, event=<optimized out>) at xselect.c:694
reply_base = {
type = 31,
xany = {
type = 31,
serial = 16882611,
send_event = 2,
display = 0x15e5800,
window = 88080627
},
xkey = {
type = 31,
serial = 16882611,
send_event = 2,
display = 0x15e5800,
window = 88080627,
root = 1,
subwindow = 324,
time = 401,
x = 162228637,
y = 0,
x_root = 0,
y_root = 500000,
state = 0,
etc
I can reliably replicate this error by opening this large file,
searching for a string that only appears on the last line and
exchange-point-and-mark'ing
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-13 10:06 ` Robert Marshall
@ 2017-12-13 14:01 ` Robert Marshall
2017-12-13 19:29 ` martin rudalics
2017-12-13 19:29 ` martin rudalics
1 sibling, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-13 14:01 UTC (permalink / raw
To: martin rudalics; +Cc: 29661
Robert Marshall <robert.marshall@codethink.co.uk> writes:
>
> I can reliably replicate this error by opening this large file,
> searching for a string that only appears on the last line and
> exchange-point-and-mark'ing
>
So this python
#!/usr/bin/python
num = 1000000
while num:
print "123456789012345678901234567890"
num = num -1
print "eureka"
redirecting output to a file, open that file with emacs -Q
incremental search for eur then C-x C-x move the cursor down one or two
lines and emacs consistently crashes for me
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-13 10:06 ` Robert Marshall
2017-12-13 14:01 ` Robert Marshall
@ 2017-12-13 19:29 ` martin rudalics
[not found] ` <87k1xp64uf.fsf@ctlt579.codethink.co.uk>
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2017-12-13 19:29 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
> Thanks, it now no longer crashes there, but crashes elsewhere but looks
> to about to terminate in a more controlled manner?
IIUC what Emacs is trying to do here is to avoid the infinite loop
mentioned in etc/PROBLEMS:
There is a long-standing bug in GTK that prevents it from recovering
from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
It also says:
If you need Emacs to be able to recover from closing displays, compile
it with the Lucid toolkit instead of GTK.
So it might be interesting if Lucid (or non-toolkit) builds work around
this.
> #1 check_glyph_memory () at dispnew.c:2264
> tail = XIL(0)
Yet another one. I attached a new patch.
martin
[-- Attachment #2: FOR_EACH_FRAME.c.diff --]
[-- Type: text/plain, Size: 1888 bytes --]
diff --git a/src/dispnew.c b/src/dispnew.c
index b0fc5c3..d078647 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -2260,8 +2260,9 @@ struct glyph_row *
Lisp_Object tail, frame;
/* Free glyph memory for all frames. */
- FOR_EACH_FRAME (tail, frame)
- free_glyphs (XFRAME (frame));
+ if (!NILP (Vframe_list))
+ FOR_EACH_FRAME (tail, frame)
+ free_glyphs (XFRAME (frame));
#if defined GLYPH_DEBUG && defined ENABLE_CHECKING
/* Check that nothing is left allocated. */
diff --git a/src/frame.c b/src/frame.c
index 5bafbed..66d1b5c 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2058,7 +2058,7 @@ of them (the selected terminal frame) is actually displayed.
/* If we've deleted the last_nonminibuf_frame, then try to find
another one. */
- if (f == last_nonminibuf_frame)
+ if (f == last_nonminibuf_frame && !NILP (Vframe_list))
{
last_nonminibuf_frame = 0;
@@ -2076,7 +2076,7 @@ of them (the selected terminal frame) is actually displayed.
/* If there's no other frame on the same kboard, get out of
single-kboard state if we're in it for this kboard. */
- if (kb != NULL)
+ if (kb != NULL && !NILP (Vframe_list))
{
/* Some frame we found on the same kboard, or nil if there are none. */
Lisp_Object frame_on_same_kboard = Qnil;
@@ -2093,7 +2093,9 @@ of them (the selected terminal frame) is actually displayed.
/* If we've deleted this keyboard's default_minibuffer_frame, try to
find another one. Prefer minibuffer-only frames, but also notice
frames with other windows. */
- if (kb != NULL && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame)))
+ if (kb != NULL
+ && EQ (frame, KVAR (kb, Vdefault_minibuffer_frame))
+ && !NILP (Vframe_list))
{
/* The last frame we saw with a minibuffer, minibuffer-only or not. */
Lisp_Object frame_with_minibuf = Qnil;
^ permalink raw reply related [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-13 14:01 ` Robert Marshall
@ 2017-12-13 19:29 ` martin rudalics
2017-12-14 8:35 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2017-12-13 19:29 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> So this python
>
> #!/usr/bin/python
> num = 1000000
> while num:
> print "123456789012345678901234567890"
> num = num -1
> print "eureka"
>
> redirecting output to a file, open that file with emacs -Q
> incremental search for eur then C-x C-x move the cursor down one or two
> lines and emacs consistently crashes for me
30 MB without newlines? This makes my Emacs pretty unresponsive here.
However, on Windows I apparently don't get such crashes.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-13 19:29 ` martin rudalics
@ 2017-12-14 8:35 ` Robert Marshall
2017-12-14 17:10 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-14 8:35 UTC (permalink / raw
To: martin rudalics; +Cc: 29661
martin rudalics <rudalics@gmx.at> writes:
>> So this python
>>
>> #!/usr/bin/python
>> num = 1000000
>> while num:
>> print "123456789012345678901234567890"
>> num = num -1
>> print "eureka"
>>
>> redirecting output to a file, open that file with emacs -Q
>> incremental search for eur then C-x C-x move the cursor down one or two
>> lines and emacs consistently crashes for me
>
> 30 MB without newlines? This makes my Emacs pretty unresponsive here.
> However, on Windows I apparently don't get such crashes.
>
A python print automatically adds a new line
I assume the windows failure to crash is because there isn't an X failure.
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-14 8:35 ` Robert Marshall
@ 2017-12-14 17:10 ` Eli Zaretskii
2017-12-15 8:49 ` martin rudalics
2017-12-15 9:24 ` Robert Marshall
0 siblings, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2017-12-14 17:10 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> From: Robert Marshall <robert.marshall@codethink.co.uk>
> Date: Thu, 14 Dec 2017 08:35:21 +0000
> Cc: 29661@debbugs.gnu.org
>
> I assume the windows failure to crash is because there isn't an X failure.
Do you perhaps have some utility installed that attempts to manage the
X clipboard and selections? If so, can you disable it and see if the
problem goes away?
Basically, the question is why does X fail or close the connection
with Emacs.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
[not found] ` <87k1xp64uf.fsf@ctlt579.codethink.co.uk>
@ 2017-12-15 8:49 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2017-12-15 8:49 UTC (permalink / raw
To: Robert Marshall, 29661
> I now get - but maybe this is anticipated:
>
> Connection lost to X server ':0'
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.
This is the expected behavior. I now installed the guards to get there
without segfaulting before.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-14 17:10 ` Eli Zaretskii
@ 2017-12-15 8:49 ` martin rudalics
2017-12-15 9:24 ` Robert Marshall
1 sibling, 0 replies; 25+ messages in thread
From: martin rudalics @ 2017-12-15 8:49 UTC (permalink / raw
To: Eli Zaretskii, Robert Marshall; +Cc: 29661
> Basically, the question is why does X fail or close the connection
> with Emacs.
Incidentally, this could be related to Bug#29690 (and the ancient
Bug#13486).
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-14 17:10 ` Eli Zaretskii
2017-12-15 8:49 ` martin rudalics
@ 2017-12-15 9:24 ` Robert Marshall
2017-12-15 10:39 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-15 9:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29661
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Marshall <robert.marshall@codethink.co.uk>
>> Date: Thu, 14 Dec 2017 08:35:21 +0000
>> Cc: 29661@debbugs.gnu.org
>>
>> I assume the windows failure to crash is because there isn't an X failure.
>
> Do you perhaps have some utility installed that attempts to manage the
> X clipboard and selections? If so, can you disable it and see if the
> problem goes away?
>
> Basically, the question is why does X fail or close the connection
> with Emacs.
I'm running the standard kde desktop which comes with klipper. If I
stop klipper - at the moment! - I can no longer replicate the error
When running klipper from the command line and replicating the problem I
see
QClipboardWatcher::empty: Internal error: Application owns the selection
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 9:24 ` Robert Marshall
@ 2017-12-15 10:39 ` Eli Zaretskii
2017-12-15 10:58 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2017-12-15 10:39 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> From: Robert Marshall <robert.marshall@codethink.co.uk>
> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
> Date: Fri, 15 Dec 2017 09:24:21 +0000
>
> > Do you perhaps have some utility installed that attempts to manage the
> > X clipboard and selections? If so, can you disable it and see if the
> > problem goes away?
> >
> > Basically, the question is why does X fail or close the connection
> > with Emacs.
>
> I'm running the standard kde desktop which comes with klipper. If I
> stop klipper - at the moment! - I can no longer replicate the error
>
> When running klipper from the command line and replicating the problem I
> see
>
> QClipboardWatcher::empty: Internal error: Application owns the selection
Ah, in that case we have an entry in PROBLEMS about klipper. Does
upgrading to a newer version as indicated there solve the problem? If
not, perhaps we should update that entry with some new information.
Thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 10:39 ` Eli Zaretskii
@ 2017-12-15 10:58 ` Robert Marshall
2017-12-15 11:11 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2017-12-15 10:58 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29661
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Marshall <robert.marshall@codethink.co.uk>
>> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
>> Date: Fri, 15 Dec 2017 09:24:21 +0000
>>
>> > Do you perhaps have some utility installed that attempts to manage the
>> > X clipboard and selections? If so, can you disable it and see if the
>> > problem goes away?
>> >
>> > Basically, the question is why does X fail or close the connection
>> > with Emacs.
>>
>> I'm running the standard kde desktop which comes with klipper. If I
>> stop klipper - at the moment! - I can no longer replicate the error
>>
>> When running klipper from the command line and replicating the problem I
>> see
>>
>> QClipboardWatcher::empty: Internal error: Application owns the selection
>
> Ah, in that case we have an entry in PROBLEMS about klipper. Does
> upgrading to a newer version as indicated there solve the problem? If
> not, perhaps we should update that entry with some new information.
>
I have 4.14.2 of kde, Klipper: 0.9.7
Which would appear to be newer than the entry in PROBLEMS - update
to say emacs may crash? And mention select-active-regions?
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 10:58 ` Robert Marshall
@ 2017-12-15 11:11 ` Eli Zaretskii
2017-12-15 13:00 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2017-12-15 11:11 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> From: Robert Marshall <robert.marshall@codethink.co.uk>
> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
> Date: Fri, 15 Dec 2017 10:58:47 +0000
>
> >> When running klipper from the command line and replicating the problem I
> >> see
> >>
> >> QClipboardWatcher::empty: Internal error: Application owns the selection
> >
> > Ah, in that case we have an entry in PROBLEMS about klipper. Does
> > upgrading to a newer version as indicated there solve the problem? If
> > not, perhaps we should update that entry with some new information.
> >
> I have 4.14.2 of kde, Klipper: 0.9.7
>
> Which would appear to be newer than the entry in PROBLEMS - update
> to say emacs may crash? And mention select-active-regions?
Please propose the text to add there, and thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 11:11 ` Eli Zaretskii
@ 2017-12-15 13:00 ` Robert Marshall
2017-12-22 10:07 ` Eli Zaretskii
2018-01-01 10:01 ` Robert Marshall
0 siblings, 2 replies; 25+ messages in thread
From: Robert Marshall @ 2017-12-15 13:00 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29661
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Marshall <robert.marshall@codethink.co.uk>
>> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
>> Date: Fri, 15 Dec 2017 10:58:47 +0000
>>
>> >> When running klipper from the command line and replicating the problem I
>> >> see
>> >>
>> >> QClipboardWatcher::empty: Internal error: Application owns the selection
>> >
>> > Ah, in that case we have an entry in PROBLEMS about klipper. Does
>> > upgrading to a newer version as indicated there solve the problem? If
>> > not, perhaps we should update that entry with some new information.
>> >
>> I have 4.14.2 of kde, Klipper: 0.9.7
>>
>> Which would appear to be newer than the entry in PROBLEMS - update
>> to say emacs may crash? And mention select-active-regions?
>
> Please propose the text to add there, and thanks.
I'll take a look at my home machine tonight - which probably has a later
version to see if the problem is still present and then suggest an
amendment.
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 13:00 ` Robert Marshall
@ 2017-12-22 10:07 ` Eli Zaretskii
2017-12-22 14:04 ` Robert Marshall
2018-01-01 10:01 ` Robert Marshall
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2017-12-22 10:07 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> From: Robert Marshall <robert.marshall@codethink.co.uk>
> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
> Date: Fri, 15 Dec 2017 13:00:58 +0000
>
> >> I have 4.14.2 of kde, Klipper: 0.9.7
> >>
> >> Which would appear to be newer than the entry in PROBLEMS - update
> >> to say emacs may crash? And mention select-active-regions?
> >
> > Please propose the text to add there, and thanks.
>
> I'll take a look at my home machine tonight - which probably has a later
> version to see if the problem is still present and then suggest an
> amendment.
Any news on this?
TIA
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-22 10:07 ` Eli Zaretskii
@ 2017-12-22 14:04 ` Robert Marshall
0 siblings, 0 replies; 25+ messages in thread
From: Robert Marshall @ 2017-12-22 14:04 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29661
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Marshall <robert.marshall@codethink.co.uk>
>> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
>> Date: Fri, 15 Dec 2017 13:00:58 +0000
>>
>> >> I have 4.14.2 of kde, Klipper: 0.9.7
>> >>
>> >> Which would appear to be newer than the entry in PROBLEMS - update
>> >> to say emacs may crash? And mention select-active-regions?
>> >
>> > Please propose the text to add there, and thanks.
>>
>> I'll take a look at my home machine tonight - which probably has a later
>> version to see if the problem is still present and then suggest an
>> amendment.
>
> Any news on this?
>
Apologies - last weekend was busier than expected - hopefully in the
break next week!
Robert
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2017-12-15 13:00 ` Robert Marshall
2017-12-22 10:07 ` Eli Zaretskii
@ 2018-01-01 10:01 ` Robert Marshall
2018-01-01 16:30 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2018-01-01 10:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Robert Marshall, 29661
On Fri, Dec 15 2017, Robert Marshall <robert.marshall@codethink.co.uk> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Robert Marshall <robert.marshall@codethink.co.uk>
>>> Cc: rudalics@gmx.at, 29661@debbugs.gnu.org
>>> Date: Fri, 15 Dec 2017 10:58:47 +0000
>>>
>>> >> When running klipper from the command line and replicating the problem I
>>> >> see
>>> >>
>>> >> QClipboardWatcher::empty: Internal error: Application owns the selection
>>> >
>>> > Ah, in that case we have an entry in PROBLEMS about klipper. Does
>>> > upgrading to a newer version as indicated there solve the problem? If
>>> > not, perhaps we should update that entry with some new information.
>>> >
>>> I have 4.14.2 of kde, Klipper: 0.9.7
With 4.14.34 of kde Klipper 5.10.5 (that's a huge version leap!) I also
see the crash. I also have the problem with clipit (v 1.4.2) which I use in
another desktop environment for clipboard management
>>>
>>> Which would appear to be newer than the entry in PROBLEMS - update
>>> to say emacs may crash? And mention select-active-regions?
Reading bug#29889 I set select-active-regions to 'only and the problem no
longer happens.
>> Please propose the text to add there, and thanks.
>
> I'll take a look at my home machine tonight - which probably has a later
> version to see if the problem is still present and then suggest an
> amendment.
>
Here's a suggested change:
----------------------------------------------------------------
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index c9b11fbc56..36df5493f4 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1034,18 +1034,17 @@ It is also reported that a bug in the gtk-engines-qt engine can cause this if
Emacs is compiled with Gtk+.
The bug is fixed in version 0.7 or newer of gtk-engines-qt.
-*** KDE: Emacs hangs on KDE when a large portion of text is killed.
+*** Clipboard: Emacs hangs or crashes when a large portion of text is selected or killed.
-This is caused by a bug in the KDE applet 'klipper' which periodically
-requests the X clipboard contents from applications. Early versions
-of klipper don't implement the ICCCM protocol for large selections,
-which leads to Emacs being flooded with selection requests. After a
-while, Emacs may print a message:
+This is caused by a bug in the clipboard management applets (it has
+been observer in 'klipper' and 'clipit') which periodically request
+the X clipboard contents from applications. After a while, Emacs may
+print a message:
Timed out waiting for property-notify event
-A workaround is to not use 'klipper'. Upgrading 'klipper' to the one
-coming with KDE 3.3 or later also solves the problem.
+A workaround is to not use 'klipper'or 'clipit'. Alternatively setting
+select-active-regions to 'only also solves the problem.
*** KDE / Plasma 5: Emacs exhausts memory and needs to be killed
----------------------------------------------------------------
Robert
^ permalink raw reply related [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2018-01-01 10:01 ` Robert Marshall
@ 2018-01-01 16:30 ` Eli Zaretskii
2018-01-01 19:11 ` Robert Marshall
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2018-01-01 16:30 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661
> From: Robert Marshall <robert@capuchin.co.uk>
> Cc: 29661@debbugs.gnu.org, Robert Marshall <robert.marshall@codethink.co.uk>
> Date: Mon, 01 Jan 2018 10:01:44 +0000
>
> >>> I have 4.14.2 of kde, Klipper: 0.9.7
>
> With 4.14.34 of kde Klipper 5.10.5 (that's a huge version leap!) I also
> see the crash. I also have the problem with clipit (v 1.4.2) which I use in
> another desktop environment for clipboard management
>
> >>>
> >>> Which would appear to be newer than the entry in PROBLEMS - update
> >>> to say emacs may crash? And mention select-active-regions?
>
> Reading bug#29889 I set select-active-regions to 'only and the problem no
> longer happens.
>
> >> Please propose the text to add there, and thanks.
> >
> > I'll take a look at my home machine tonight - which probably has a later
> > version to see if the problem is still present and then suggest an
> > amendment.
> >
>
> Here's a suggested change:
Thanks, I committed it with a few changes.
I guess we can now close this bug?
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2018-01-01 16:30 ` Eli Zaretskii
@ 2018-01-01 19:11 ` Robert Marshall
2018-01-01 20:03 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Robert Marshall @ 2018-01-01 19:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29661
Eli Zaretskii writes:
> > From: Robert Marshall <robert@capuchin.co.uk>
> > Cc: 29661@debbugs.gnu.org, Robert Marshall <robert.marshall@codethink.co.uk>
> > Date: Mon, 01 Jan 2018 10:01:44 +0000
> >
> > >>> I have 4.14.2 of kde, Klipper: 0.9.7
> >
> > With 4.14.34 of kde Klipper 5.10.5 (that's a huge version leap!) I also
> > see the crash. I also have the problem with clipit (v 1.4.2) which I use in
> > another desktop environment for clipboard management
> >
> > >>>
> > >>> Which would appear to be newer than the entry in PROBLEMS - update
> > >>> to say emacs may crash? And mention select-active-regions?
> >
> > Reading bug#29889 I set select-active-regions to 'only and the problem no
> > longer happens.
> >
> > >> Please propose the text to add there, and thanks.
> > >
> > > I'll take a look at my home machine tonight - which probably has a later
> > > version to see if the problem is still present and then suggest an
> > > amendment.
> > >
> >
> > Here's a suggested change:
>
> Thanks, I committed it with a few changes.
>
> I guess we can now close this bug?
>
I'm happy for that to happen - though I wondered if it should be moved
(or a reference placed ) in the Crash bugs section of that file?
Robert
--
Robert Marshall twitter: @rajm
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark
2018-01-01 19:11 ` Robert Marshall
@ 2018-01-01 20:03 ` Eli Zaretskii
0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2018-01-01 20:03 UTC (permalink / raw
To: Robert Marshall; +Cc: 29661-done
> Date: Mon, 1 Jan 2018 19:11:51 +0000
> From: Robert Marshall <robert@capuchin.co.uk>
> Cc: 29661@debbugs.gnu.org
>
> > I guess we can now close this bug?
> >
>
> I'm happy for that to happen - though I wondered if it should be moved
> (or a reference placed ) in the Crash bugs section of that file?
I'm not sure, because Emacs doesn't always crash due to this issue.
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2018-01-01 20:03 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-11 15:22 bug#29661: 27.0.50; emacs crashing on exchange-point-and-mark Robert Marshall
2017-12-12 8:56 ` martin rudalics
2017-12-12 9:49 ` Robert Marshall
2017-12-12 10:28 ` martin rudalics
2017-12-12 10:55 ` Robert Marshall
2017-12-13 8:48 ` martin rudalics
2017-12-13 10:06 ` Robert Marshall
2017-12-13 14:01 ` Robert Marshall
2017-12-13 19:29 ` martin rudalics
2017-12-14 8:35 ` Robert Marshall
2017-12-14 17:10 ` Eli Zaretskii
2017-12-15 8:49 ` martin rudalics
2017-12-15 9:24 ` Robert Marshall
2017-12-15 10:39 ` Eli Zaretskii
2017-12-15 10:58 ` Robert Marshall
2017-12-15 11:11 ` Eli Zaretskii
2017-12-15 13:00 ` Robert Marshall
2017-12-22 10:07 ` Eli Zaretskii
2017-12-22 14:04 ` Robert Marshall
2018-01-01 10:01 ` Robert Marshall
2018-01-01 16:30 ` Eli Zaretskii
2018-01-01 19:11 ` Robert Marshall
2018-01-01 20:03 ` Eli Zaretskii
2017-12-13 19:29 ` martin rudalics
[not found] ` <87k1xp64uf.fsf@ctlt579.codethink.co.uk>
2017-12-15 8:49 ` martin rudalics
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.