* bug#25875: 26.0.50; Hang logging out of MS-Windows
@ 2017-02-25 19:35 Richard Copley
2017-02-25 19:41 ` Richard Copley
2017-02-25 20:33 ` Eli Zaretskii
0 siblings, 2 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-25 19:35 UTC (permalink / raw)
To: 25875
On MS Windows, Emacs sometimes hangs when shutting down or logging out.
(This build includes 5114b3a204..: Eli Zaretskii 2017-02-23 Avoid
quitting inside a critical section on MS-Windows, see #25279).
I've included backtraces for all the threads having Emacs functions on
the stack, because I can't tell which are deadlocked, if any. (2 and 3?)
Also got these from thread 2, frame 2.
(gdb) print crit
$1 = (CRITICAL_SECTION *) 0x401bc6a20 <crit_real>
(gdb) print crit_real
$2 = {DebugInfo = 0xffffffffffffffff, LockCount = -1, RecursionCount = 0,
OwningThread = 0x0, LockSemaphore = 0x0, SpinCount = 33556432}
Backtraces:
Thread 4 (Thread 9488.0x1194):
#0 0x00007ffffe2c6154 in ntdll!ZwWaitForSingleObject ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x00007ffffae075ff in WaitForSingleObjectEx ()
from C:\Windows\System32\KernelBase.dll
No symbol table info available.
#2 0x0000000400271b98 in _sys_wait_accept (fd=3) at ../../repo/src/w32.c:8514
hEv = 0x8c
cp = 0x401bc5680 <child_procs>
rc = 258
#3 0x000000040027a86a in reader_thread (arg=0x401bc5680 <child_procs>)
at ../../repo/src/w32proc.c:1151
rc = 0
cp = 0x401bc5680 <child_procs>
#4 0x00007ffffc188364 in KERNEL32!BaseThreadInitThunk ()
from C:\Windows\System32\kernel32.dll
No symbol table info available.
#5 0x00007ffffe2870d1 in ntdll!RtlUserThreadStart ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 3 (Thread 9488.0x8cc):
#0 0x00007ffffe2c6754 in ntdll!ZwDelayExecution ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x00007ffffae3c4a7 in SleepEx () from C:\Windows\System32\KernelBase.dll
No symbol table info available.
#2 0x0000000400266caf in sys_sleep (seconds=1000)
at ../../repo/src/w32.c:3075
No locals.
#3 0x0000000400238225 in w32_wnd_proc (hwnd=0x1f076a, msg=22, wParam=1,
lParam=0) at ../../repo/src/w32fns.c:4805
f = 0xd345b0
dpyinfo = 0x4006b59c0 <one_w32_display_info>
wmsg = {msg = {hwnd = 0x1f076a, message = 22, wParam = 1, lParam = 0,
time = 257387359, pt = {x = 0, y = 101016963}},
dwModifiers = 13659424, rect = {left = 0, top = 1050102, right = 0,
bottom = 43396736}}
windows_translate = 0
key = 77854497
#4 0x00007ffffc381c24 in USER32!CallWindowProcW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#5 0x00007ffffc381917 in USER32!CallWindowProcW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#6 0x00007ffffc392563 in USER32!MapWindowPoints ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#7 0x00007ffffe2c9c54 in ntdll!KiUserCallbackDispatcher ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#8 0x00007ffffb011184 in win32u!NtUserMessageCall ()
from C:\Windows\System32\win32u.dll
No symbol table info available.
#9 0x00007ffffc37ee4d in USER32!GetWindowTextW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#10 0x00007ffffc37eb52 in USER32!GetWindowTextW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#11 0x00000004002389df in w32_wnd_proc (hwnd=0x1f076a, msg=59, wParam=1292,
lParam=0) at ../../repo/src/w32fns.c:5019
f = 0x2975c40
dpyinfo = 0x4006b59c0 <one_w32_display_info>
wmsg = {msg = {hwnd = 0xd34d90, message = 43036800, wParam = 1,
lParam = 140737424911660, time = 1321741036, pt = {x = 32866,
y = -31153514}}, dwModifiers = 0, rect = {left = 0,
top = -119665741, right = 32767, bottom = 77855528}}
windows_translate = 32767
key = -75708142
#12 0x00007ffffc381c24 in USER32!CallWindowProcW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#13 0x00007ffffc381917 in USER32!CallWindowProcW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#14 0x00007ffffc392563 in USER32!MapWindowPoints ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#15 0x00007ffffe2c9c54 in ntdll!KiUserCallbackDispatcher ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#16 0x00007ffffb011164 in win32u!NtUserGetMessage ()
from C:\Windows\System32\win32u.dll
No symbol table info available.
#17 0x00007ffffc394866 in USER32!GetMessageW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#18 0x0000000400234b8b in w32_msg_pump (msg_buf=0x4a3fec0)
at ../../repo/src/w32fns.c:2934
msg = {hwnd = 0x360858, message = 49585, wParam = 0, lParam = 0,
time = 257387359, pt = {x = 147, y = 1339}}
result = 0
focus_window = 0x7ffffc398c05 <USER32!PostThreadMessageA+101>
#19 0x0000000400234e2b in w32_msg_worker (arg=0x0)
at ../../repo/src/w32fns.c:3157
msg = {hwnd = 0x0, message = 0, wParam = 0, lParam = 0, time = 0,
pt = {x = 0, y = 0}}
dummy_buf = {next = 0x0, w32msg = {msg = {hwnd = 0x0, message = 0,
wParam = 0, lParam = 0, time = 0, pt = {x = 0, y = 0}},
dwModifiers = 0, rect = {left = 0, top = 0, right = 0,
bottom = 0}}, result = 0, completed = 0}
#20 0x00007ffffc188364 in KERNEL32!BaseThreadInitThunk ()
from C:\Windows\System32\kernel32.dll
No symbol table info available.
#21 0x00007ffffe2870d1 in ntdll!RtlUserThreadStart ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#22 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 2 (Thread 9488.0x1a84):
#0 0x00007ffffe2c6754 in ntdll!ZwDelayExecution ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x00007ffffae3c4a7 in SleepEx () from C:\Windows\System32\KernelBase.dll
No symbol table info available.
#2 0x0000000400279469 in timer_loop (arg=0x401bc69a0 <real_itimer>)
at ../../repo/src/w32proc.c:383
sleep_time = 5
handler = 0x400218057 <handle_alarm_signal>
now = 13132522579521
expire = 0
reload = 0
itimer = 0x401bc69a0 <real_itimer>
which = 0
sig = 14
crit = 0x401bc6a20 <crit_real>
max_sleep = 30
hth = 0x0
#3 0x00007ffffc188364 in KERNEL32!BaseThreadInitThunk ()
from C:\Windows\System32\kernel32.dll
No symbol table info available.
#4 0x00007ffffe2870d1 in ntdll!RtlUserThreadStart ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 1 (Thread 9488.0x19f8):
#0 0x00007ffffb011184 in win32u!NtUserMessageCall ()
from C:\Windows\System32\win32u.dll
No symbol table info available.
#1 0x00007ffffc38116d in USER32!SendMessageW ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#2 0x00007ffffc3883e5 in USER32!SendMessageA ()
from C:\Windows\System32\user32.dll
No symbol table info available.
#3 0x0000000400254af2 in my_show_window (
f=0x400a51890 <dumped_data+3722384>, hwnd=0x6f0230, how=1)
at ../../repo/src/w32term.c:3671
No locals.
#4 0x0000000400255463 in w32_set_vertical_scroll_bar (w=0x134bdb0,
portion=375, whole=375, position=0) at ../../repo/src/w32term.c:3864
hwnd = 0x6f0230
f = 0x400a51890 <dumped_data+3722384>
barobj = 1
bar = 0x1391040
top = 676
height = 666
left = 1261
width = 17
window_y = 676
window_height = 666
#5 0x000000040004e243 in set_vertical_scroll_bar (w=0x134bdb0)
at ../../repo/src/xdisp.c:16147
start = 0
end = 375
whole = 375
#6 0x0000000400052dfd in redisplay_window (window=20233653,
just_this_one_p=true) at ../../repo/src/xdisp.c:17309
w = 0x134bdb0
f = 0x400a51890 <dumped_data+3722384>
buffer = 0x88363c0
old = 0x88363c0
lpoint = {charpos = 376, bytepos = 376}
opoint = {charpos = 376, bytepos = 376}
startp = {charpos = 1, bytepos = 1}
update_mode_line = false
tem = 1058053
it = {window = 14, w = 0x1, f = 0x0, method = 9440213,
stop_charpos = 2295024, prev_stop = 74, base_level_stop = 12568888,
end_charpos = 17181950771,
s = 0x2 <error: Cannot access memory at address 0x2>,
string_nchars = 12567928, redisplay_end_trigger_charpos = 12567936,
multibyte_p = false, header_line_p = false,
string_from_display_prop_p = true,
string_from_prefix_prop_p = true, from_disp_prop_p = false,
ellipsis_p = false, avoid_cursor_p = false, dp = 0xbfc5a0,
dpvec = 0x134bdb5, dpend = 0x91415d1, dpvec_char_len = 0,
dpvec_face_id = 0, saved_face_id = 152311249, ctl_chars = {
17181635588, 2, 12, 12568016, 17180927016, 17183781845,
142828480, 2342752262226706883, 2361576154760218624,
2342752270235894845, 10841447192854784, 200691974110511369,
144781496436181537, 578158424060201565, 5153595279354005796,
-5322406194155435264}, start = {pos = {charpos = 17181935493,
bytepos = 17183781845}, overlay_string_index = 17180925455,
string_pos = {charpos = 17186823872, bytepos = 10},
dpvec_index = 170}, current = {pos = {charpos = 0,
bytepos = 12568272}, overlay_string_index = 17181642413,
string_pos = {charpos = 0, bytepos = 1},
dpvec_index = 152311249}, n_overlay_strings = 17180926156,
overlay_strings_charpos = 141772579, overlay_strings = {
17181115979, 142828485, 141772579, 12568352, 17181465465,
141772579, 0, 12568288, 17180925455, 17186823872, 17180926961,
17182871045, 0, 12568432, 17181466204, 0}, string_overlays = {0,
17186823872, 17180927016, 17182871045, 2, 12569240, 17181950771,
0, 12570112, 17182871008, 2992679347674122353,
-5620449992977792767, 64, 0, 141772579, 0}, string = 12552128,
from_overlay = 12568496, stack = {{string = 17180937994,
string_nchars = 26, end_charpos = 0, stop_charpos = 0,
prev_stop = 0, base_level_stop = 12568560, cmp_it = {
stop_pos = 12568952, id = 12568560, ch = 1763084,
rule_idx = 2, lookback = 0, nglyphs = 12568592,
reversed_p = false, charpos = 17180925455, nchars = 6954688,
nbytes = 4, from = 1766404, to = 4, width = 2},
face_id = 12568952, u = {image = {object = 0, slice = {
x = 2294856, y = 142828480, width = 1, height = 1},
image_id = 1}, stretch = {object = 0}, xwidget = {
object = 0}}, position = {charpos = 1, bytepos = 257},
current = {pos = {charpos = 12568000, bytepos = 12568000},
overlay_string_index = 142828485, string_pos = {
charpos = 16214, bytepos = 12}, dpvec_index = 74},
from_overlay = 12, area = 1056271, method = GET_FROM_IMAGE,
paragraph_embedding = (unknown: 6954688), multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = true, display_ellipsis_p = false,
avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false,
line_wrap = (WINDOW_WRAP | unknown: 8), voffset = 0,
space_width = 12568952, font_height = 0}, {string = 12568896,
string_nchars = 1773229, end_charpos = 0,
stop_charpos = 17189309397, prev_stop = 579833153792,
base_level_stop = 1, cmp_it = {stop_pos = 1, id = 14,
ch = 12568074, rule_idx = 12568000, lookback = 12567928,
nglyphs = 12567904, reversed_p = false, charpos = 12568912,
nchars = 14, nbytes = 0, from = 12568912, to = 16777216,
width = 3912664}, face_id = 3912581, u = {image = {
object = 12569792, slice = {x = 17183781845, y = 46,
width = 12569056, height = 17181637421},
image_id = 17183781812}, stretch = {object = 12569792},
xwidget = {object = 12569792}}, position = {
charpos = 17183781845, bytepos = 46}, current = {pos = {
charpos = 1030, bytepos = 1},
overlay_string_index = 12569800, string_pos = {
charpos = 12569040, bytepos = 17180927237},
dpvec_index = 5}, from_overlay = 14, area = 12568440,
method = GET_FROM_BUFFER,
paragraph_embedding = (unknown: 12568440), multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false, display_ellipsis_p = false,
avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = (unknown: 12569168),
voffset = 0, space_width = 17183781760, font_height = 1030}, {
string = 17180931301, string_nchars = 3912581,
end_charpos = 2294352, stop_charpos = 17183782093,
prev_stop = 26, base_level_stop = 12569232, cmp_it = {
stop_pos = 17181635290, id = 128004720, ch = 1, rule_idx = 1,
lookback = 17180925455, nglyphs = 6971376, reversed_p = 4,
charpos = 0, nchars = 12569200, nbytes = 0, from = 1056271,
to = 4, width = 6954688}, face_id = 3912581, u = {image = {
object = 17179869482, slice = {x = 2294352, y = 12569248,
width = 17181632136, height = 0}, image_id = 12569784},
stretch = {object = 17179869482}, xwidget = {
object = 17179869482}}, position = {charpos = 142828480,
bytepos = 12569784}, current = {pos = {charpos = 12569392,
bytepos = 17181633156}, overlay_string_index = 2,
string_pos = {charpos = 12569784, bytepos = 12569328},
dpvec_index = 1068810}, from_overlay = 2295024,
area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR, multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false, display_ellipsis_p = false,
avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0,
space_width = 12569392, font_height = 12569784}, {
string = 12569392, string_nchars = 1763084, end_charpos = 2,
stop_charpos = 0, prev_stop = 12569424,
base_level_stop = 17180925455, cmp_it = {
stop_pos = 17186823872, id = 17181635588, ch = 2,
rule_idx = 12569784, lookback = 12569568, nglyphs = 1246858,
reversed_p = 4, charpos = 142828480, nchars = 1766106,
nbytes = 4, from = 12569520, to = 0, width = 0},
face_id = 12569536, u = {image = {object = 0, slice = {
x = 12569632, y = 17181641459, width = 142828485,
height = 142828480}, image_id = 12569664}, stretch = {
object = 0}, xwidget = {object = 0}}, position = {
charpos = 0, bytepos = 12569584}, current = {pos = {
charpos = 17180925455, bytepos = 17186823872},
overlay_string_index = 10, string_pos = {charpos = 12569784,
bytepos = 0}, dpvec_index = 12569728},
from_overlay = 17181642413, area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER, paragraph_embedding = L2R,
multibyte_p = false, string_from_display_prop_p = false,
string_from_prefix_prop_p = false, display_ellipsis_p = false,
avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false, line_wrap = (unknown: 12569664),
voffset = 0, space_width = 17180926156,
font_height = 145285235}, {string = 17181115979,
string_nchars = 142828485, end_charpos = 145285235,
stop_charpos = 12569808, prev_stop = 17181465465,
base_level_stop = 145285235, cmp_it = {stop_pos = 0,
id = 12569744, ch = 1056271, rule_idx = 17186823872,
lookback = 17180926961, nglyphs = 3001861, reversed_p = 4,
charpos = 0, nchars = 12569888, nbytes = 0, from = 1597020,
to = 4, width = 0}, face_id = 0, u = {image = {
object = 17186823872, slice = {x = 17180927016,
y = 17182871045, width = 2, height = 12570696},
image_id = 17181950771}, stretch = {object = 17186823872},
xwidget = {object = 17186823872}}, position = {charpos = 0,
bytepos = 12571552}, current = {pos = {charpos = 17182871008,
bytepos = -8824482654938807040},
overlay_string_index = 2378394774681485375, string_pos = {
charpos = 145285235, bytepos = 0}, dpvec_index = 2066368},
from_overlay = 17182871045, area = 9449133,
method = GET_FROM_IMAGE,
paragraph_embedding = (unknown: 12570048), multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false, display_ellipsis_p = false,
avoid_cursor_p = false, bidi_p = false,
from_disp_prop_p = false,
line_wrap = (WINDOW_WRAP | unknown: 1766104), voffset = 4,
space_width = 26, font_height = 0}}, sp = 12570104,
selective = 0, what = 12570096, face_id = 0,
selective_display_ellipsis_p = false, ctl_arrow_p = false,
face_box_p = false, start_of_box_run_p = true,
end_of_box_run_p = false,
overlay_strings_at_end_processed_p = false,
ignore_overlay_strings_at_pos_p = true,
glyph_not_available_p = true, starts_in_middle_of_char_p = true,
face_before_selective_p = false,
constrain_row_ascent_descent_p = false, line_wrap = TRUNCATE,
base_face_id = 11, c = 0, len = 2, cmp_it = {stop_pos = 0,
id = 17186043925, ch = 12570048, rule_idx = 10,
lookback = 12570936, nglyphs = 2081587, reversed_p = 4,
charpos = 3, nchars = 12570096, nbytes = 0, from = 12570112,
to = 0, width = 1057777}, char_to_display = 12570112,
glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE,
image_id = 17180926851,
xwidget = 0x4008ff2f0 <dumped_data+2336496>, slice = {
x = 141772563, y = 0, width = 488880, height = 0},
space_width = 198933024476414400, voffset = -30942,
tab_width = 144, font_height = 1, object = 145775491, position = {
charpos = 17182874605, bytepos = 50}, truncation_pixel_width = 0,
continuation_pixel_width = 0, first_visible_x = 0,
last_visible_x = 12570320, last_visible_y = 0,
extra_line_spacing = 1762026, max_extra_line_spacing = 4,
override_ascent = 2, override_descent = 0,
override_boff = 12570712, glyph_row = 0x8734713, area = 376,
nglyphs = 0, pixel_width = 6954688, ascent = 4, descent = 6946944,
max_ascent = 4, max_descent = 12570336, phys_ascent = 0,
phys_descent = 1590270, max_phys_ascent = 4,
max_phys_descent = 12570400, current_x = 0,
continuation_lines_width = 1, eol_pos = {charpos = 12,
bytepos = 16384}, current_y = 12570336, first_vpos = 0,
vpos = 488880, hpos = 0, left_user_fringe_bitmap = 52547,
right_user_fringe_bitmap = 2355, left_user_fringe_face_id = 0,
right_user_fringe_face_id = 22, bidi_p = false, bidi_it = {
bytepos = 12570712, charpos = 17189318317, ch = 12570512,
nchars = 17181635588, ch_len = 12749904, type = UNKNOWN_BT,
type_after_wn = UNKNOWN_BT, orig_type = 12570416,
resolved_level = 0 '\000', isolate_level = 0 '\000',
invalid_levels = 17180925455, invalid_isolates = 17186823872,
prev = {charpos = 17181515738, type = 130187789,
orig_type = UNKNOWN_BT}, last_strong = {charpos = 0,
type = 12570480, orig_type = UNKNOWN_BT}, next_for_neutral = {
charpos = 0, type = 4294967295, orig_type = 2147483647},
prev_for_neutral = {charpos = 0, type = UNKNOWN_BT,
orig_type = 16777216}, next_for_ws = {charpos = 128,
type = 12569880, orig_type = UNKNOWN_BT},
bracket_pairing_pos = 12569880, bracket_enclosed_type = 12570528,
next_en_pos = 16358, next_en_type = WEAK_EN, sos = NEUTRAL_DIR,
scan_dir = 2, disp_pos = 1, disp_prop = 6, stack_idx = 4,
level_stack = {{next_for_neutral_pos = 12570672,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12570592,
next_for_neutral_type = 5, last_strong_type = 4,
prev_for_neutral_type = 4, level = 16 '\020',
flags = 0 '\000'}, {next_for_neutral_pos = 142828485,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12570720,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 579820584961,
next_for_neutral_type = 1, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 3, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12569882,
next_for_neutral_type = 0, last_strong_type = 3,
prev_for_neutral_type = 4, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 12569872,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 4, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 12570720,
next_for_neutral_type = 3, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 72057594050498656,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 0, level = 45 '-', flags = 0 '\000'},
{next_for_neutral_pos = 17182874605, next_for_neutral_type = 0,
last_strong_type = 4, prev_for_neutral_type = 6,
level = 191 '▒', flags = 0 '\000'}, {
next_for_neutral_pos = 17182871045,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12570864,
next_for_neutral_type = 5, last_strong_type = 5,
prev_for_neutral_type = 4, level = 26 '\032',
flags = 0 '\000'}, {next_for_neutral_pos = 17182871012,
next_for_neutral_type = 5, last_strong_type = 0,
prev_for_neutral_type = 0, level = 45 '-', flags = 0 '\000'},
{next_for_neutral_pos = 10, next_for_neutral_type = 2,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 1, next_for_neutral_type = 0,
last_strong_type = 4, prev_for_neutral_type = 6,
level = 191 '▒', flags = 0 '\000'}, {
next_for_neutral_pos = 12570848, next_for_neutral_type = 5,
last_strong_type = 0, prev_for_neutral_type = 4,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 6, next_for_neutral_type = 3,
last_strong_type = 1, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 17186823872,
next_for_neutral_type = 3, last_strong_type = 2,
prev_for_neutral_type = 5, level = 115 's', flags = 8 '\b'}, {
next_for_neutral_pos = 12570976, next_for_neutral_type = 0,
last_strong_type = 5, prev_for_neutral_type = 7,
level = 45 '-', flags = 0 '\000'}, {
next_for_neutral_pos = 514, next_for_neutral_type = 5,
last_strong_type = 4, prev_for_neutral_type = 3,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17182874605,
next_for_neutral_type = 3, last_strong_type = 4,
prev_for_neutral_type = 1, level = 168 '▒', flags = 8 '\b'}, {
next_for_neutral_pos = 0, next_for_neutral_type = 2,
last_strong_type = 2, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12571040, next_for_neutral_type = 2,
last_strong_type = 3, prev_for_neutral_type = 3,
level = 26 '\032', flags = 0 '\000'}, {
next_for_neutral_pos = 128004600, next_for_neutral_type = 1,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 1, next_for_neutral_type = 1,
last_strong_type = 4, prev_for_neutral_type = 5,
level = 120 'x', flags = 8 '\b'}, {
next_for_neutral_pos = 145285219, next_for_neutral_type = 0,
last_strong_type = 6, prev_for_neutral_type = 6,
level = 7 '\a', flags = 0 '\000'}, {
next_for_neutral_pos = 10, next_for_neutral_type = 1,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 0, next_for_neutral_type = 5,
last_strong_type = 5, prev_for_neutral_type = 7,
level = 45 '-', flags = 0 '\000'}, {
next_for_neutral_pos = 12571040, next_for_neutral_type = 3,
last_strong_type = 4, prev_for_neutral_type = 1,
level = 168 '▒', flags = 8 '\b'}, {
next_for_neutral_pos = 12571152, next_for_neutral_type = 2,
last_strong_type = 5, prev_for_neutral_type = 3,
level = 26 '\032', flags = 0 '\000'}, {
next_for_neutral_pos = 2, next_for_neutral_type = 0,
last_strong_type = 3, prev_for_neutral_type = 6,
level = 191 '▒', flags = 0 '\000'}, {
next_for_neutral_pos = 12571088, next_for_neutral_type = 5,
last_strong_type = 1, prev_for_neutral_type = 0,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 131325225775263212,
next_for_neutral_type = 1, last_strong_type = 2,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {
next_for_neutral_pos = 131325225775263212,
next_for_neutral_type = 3, last_strong_type = 0,
prev_for_neutral_type = 5, level = 115 's', flags = 8 '\b'}, {
next_for_neutral_pos = 0, next_for_neutral_type = 1,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 10, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12571168, next_for_neutral_type = 0,
last_strong_type = 6, prev_for_neutral_type = 6,
level = 7 '\a', flags = 0 '\000'}, {
next_for_neutral_pos = 17186823872,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571544,
next_for_neutral_type = 5, last_strong_type = 5,
prev_for_neutral_type = 2, level = 144 '\220',
flags = 0 '\000'}, {next_for_neutral_pos = 12571344,
next_for_neutral_type = 4, last_strong_type = 0,
prev_for_neutral_type = 0, level = 26 '\032',
flags = 0 '\000'}, {next_for_neutral_pos = 2,
next_for_neutral_type = 0, last_strong_type = 3,
prev_for_neutral_type = 6, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 6, last_strong_type = 7,
prev_for_neutral_type = 7, level = 39 '\'',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 7, last_strong_type = 6,
prev_for_neutral_type = 2, level = 39 '\'',
flags = 0 '\000'}, {next_for_neutral_pos = 1794720,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571312,
next_for_neutral_type = 5, last_strong_type = 0,
prev_for_neutral_type = 4, level = 16 '\020',
flags = 0 '\000'}, {next_for_neutral_pos = 17186043920,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571328,
next_for_neutral_type = 4, last_strong_type = 1,
prev_for_neutral_type = 3, level = 16 '\020',
flags = 0 '\000'}, {next_for_neutral_pos = 12571440,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 0, level = 94 '^', flags = 0 '\000'},
{next_for_neutral_pos = 12571360, next_for_neutral_type = 4,
last_strong_type = 5, prev_for_neutral_type = 3,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17186043925,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571544,
next_for_neutral_type = 5, last_strong_type = 5,
prev_for_neutral_type = 2, level = 144 '\220',
flags = 0 '\000'}, {next_for_neutral_pos = 12571504,
next_for_neutral_type = 2, last_strong_type = 3,
prev_for_neutral_type = 3, level = 26 '\032',
flags = 0 '\000'}, {next_for_neutral_pos = 128004560,
next_for_neutral_type = 2, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571544,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571552,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 7, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 9,
next_for_neutral_type = 2, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 5, last_strong_type = 2,
prev_for_neutral_type = 0, level = 94 '^', flags = 0 '\000'},
{next_for_neutral_pos = 12571600, next_for_neutral_type = 2,
last_strong_type = 1, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12572392, next_for_neutral_type = 3,
last_strong_type = 6, prev_for_neutral_type = 4,
level = 31 '\037', flags = 0 '\000'}, {
next_for_neutral_pos = 3, next_for_neutral_type = 0,
last_strong_type = 2, prev_for_neutral_type = 6,
level = 191 '▒', flags = 0 '\000'}, {
next_for_neutral_pos = 12571568, next_for_neutral_type = 1,
last_strong_type = 6, prev_for_neutral_type = 7,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 12571568, next_for_neutral_type = 3,
last_strong_type = 4, prev_for_neutral_type = 1,
level = 168 '▒', flags = 8 '\b'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 0, last_strong_type = 6,
prev_for_neutral_type = 6, level = 7 '\a', flags = 0 '\000'},
{next_for_neutral_pos = 0, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 7,
level = 2 '\002', flags = 34 '"'}, {
next_for_neutral_pos = 34594, next_for_neutral_type = 7,
last_strong_type = 1, prev_for_neutral_type = 3,
level = 31 '\037', flags = 0 '\000'}, {
next_for_neutral_pos = 17189318317,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 7, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 2,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 50,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 17186823872,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 5, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 17182852876,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 145285219,
next_for_neutral_type = 5, last_strong_type = 5,
prev_for_neutral_type = 2, level = 27 '\033',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 1, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 2,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 3,
next_for_neutral_type = 5, last_strong_type = 4,
prev_for_neutral_type = 0, level = 4 '\004',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 5, last_strong_type = 0,
prev_for_neutral_type = 7, level = 131 '▒', flags = 8 '\b'}, {
next_for_neutral_pos = 0, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 20213088, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12571920, next_for_neutral_type = 6,
last_strong_type = 2, prev_for_neutral_type = 4,
level = 4 '\004', flags = 0 '\000'}, {
next_for_neutral_pos = 5, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 17187299840,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 5, level = 56 '8', flags = 9 '\t'}, {
next_for_neutral_pos = 12571872, next_for_neutral_type = 4,
last_strong_type = 7, prev_for_neutral_type = 0,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 154669397, next_for_neutral_type = 6,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12571920, next_for_neutral_type = 5,
last_strong_type = 0, prev_for_neutral_type = 4,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 12571920, next_for_neutral_type = 0,
last_strong_type = 5, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12571936, next_for_neutral_type = 7,
last_strong_type = 1, prev_for_neutral_type = 0,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17186871528,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 7, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 154669397,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572080,
next_for_neutral_type = 7, last_strong_type = 2,
prev_for_neutral_type = 5, level = 32 ' ', flags = 0 '\000'},
{next_for_neutral_pos = 851, next_for_neutral_type = 6,
last_strong_type = 7, prev_for_neutral_type = 7,
level = 39 '\'', flags = 0 '\000'}, {
next_for_neutral_pos = 12572016, next_for_neutral_type = 3,
last_strong_type = 1, prev_for_neutral_type = 3,
level = 32 ' ', flags = 0 '\000'}, {
next_for_neutral_pos = 1023, next_for_neutral_type = 0,
last_strong_type = 6, prev_for_neutral_type = 3,
level = 191 '▒', flags = 0 '\000'}, {
next_for_neutral_pos = 10, next_for_neutral_type = 0,
last_strong_type = 0, prev_for_neutral_type = 0,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12572192, next_for_neutral_type = 6,
last_strong_type = 2, prev_for_neutral_type = 3,
level = 26 '\032', flags = 0 '\000'}, {
next_for_neutral_pos = 154669397, next_for_neutral_type = 0,
last_strong_type = 4, prev_for_neutral_type = 4,
level = 94 '^', flags = 0 '\000'}, {
next_for_neutral_pos = 12572096, next_for_neutral_type = 4,
last_strong_type = 5, prev_for_neutral_type = 3,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17186049829,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 5, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 12572272,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572160,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572160,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {
next_for_neutral_pos = 9223372036854775807,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 72057611217797120,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 2, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12571560,
next_for_neutral_type = 0, last_strong_type = 5,
prev_for_neutral_type = 6, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 12572320,
next_for_neutral_type = 7, last_strong_type = 1,
prev_for_neutral_type = 7, level = 24 '\030',
flags = 0 '\000'}, {next_for_neutral_pos = 17186406304,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 4,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 7, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572320,
next_for_neutral_type = 5, last_strong_type = 2,
prev_for_neutral_type = 7, level = 27 '\033',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 3, last_strong_type = 4,
prev_for_neutral_type = 2, level = 232 '▒', flags = 7 '\a'}, {
next_for_neutral_pos = 131854557, next_for_neutral_type = 0,
last_strong_type = 1, prev_for_neutral_type = 6,
level = 6 '\006', flags = 0 '\000'}, {
next_for_neutral_pos = 132654211, next_for_neutral_type = 0,
last_strong_type = 4, prev_for_neutral_type = 3,
level = 0 '\000', flags = 0 '\000'}, {
next_for_neutral_pos = 12572336, next_for_neutral_type = 3,
last_strong_type = 2, prev_for_neutral_type = 5,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17186406304,
next_for_neutral_type = 6, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 0, last_strong_type = 4,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572480,
next_for_neutral_type = 2, last_strong_type = 1,
prev_for_neutral_type = 6, level = 25 '\031',
flags = 0 '\000'}, {next_for_neutral_pos = 17186406304,
next_for_neutral_type = 1, last_strong_type = 1,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 142828480,
next_for_neutral_type = 0, last_strong_type = 6,
prev_for_neutral_type = 2, level = 144 '\220',
flags = 0 '\000'}, {next_for_neutral_pos = 17189318357,
next_for_neutral_type = 0, last_strong_type = 1,
prev_for_neutral_type = 3, level = 191 '▒',
flags = 0 '\000'}, {next_for_neutral_pos = 17186406304,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 7, level = 131 '▒', flags = 8 '\b'}, {
next_for_neutral_pos = 12572464, next_for_neutral_type = 7,
last_strong_type = 1, prev_for_neutral_type = 0,
level = 16 '\020', flags = 0 '\000'}, {
next_for_neutral_pos = 17186823872,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 5, level = 106 'j',
flags = 0 '\000'}, {next_for_neutral_pos = 18,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572608,
next_for_neutral_type = 3, last_strong_type = 3,
prev_for_neutral_type = 4, level = 25 '\031',
flags = 0 '\000'}, {next_for_neutral_pos = 33936,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 0,
next_for_neutral_type = 2, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 12572656,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}, {next_for_neutral_pos = 17186406304,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 3, level = 144 '\220',
flags = 0 '\000'}, {next_for_neutral_pos = 514,
next_for_neutral_type = 0, last_strong_type = 2,
prev_for_neutral_type = 5, level = 106 'j',
flags = 0 '\000'}, {next_for_neutral_pos = 17189318357,
next_for_neutral_type = 0, last_strong_type = 0,
prev_for_neutral_type = 0, level = 0 '\000',
flags = 0 '\000'}}, string = {lstring = 12572720,
s = 0x4001b0c04 <do_one_unbind+375>
"▒mH▒M▒▒\t▒▒▒H▒E▒H▒M▒▒O▒▒▒H▒E▒H▒M▒▒\025▒▒▒H▒E▒H▒U▒H▒E▒H▒▒▒^\n▒▒H▒ù",
schars = 33936, bufpos = 0,
from_disp_str = false, unibyte = true}, w = 0x0,
paragraph_dir = (unknown: 12572672),
separator_limit = 17180925455, first_elt = false,
new_paragraph = false, frame_window_p = false},
paragraph_embedding = (unknown: 33936)}
current_matrix_up_to_date_p = true
used_current_matrix_p = true
buffer_unchanged_p = true
temp_scroll_step = false
count = 6
rc = 0
centering_position = -1
last_line_misfit = false
beg_unchanged = 293
end_unchanged = 82
frame_line_height = 18
margin = 0
use_desired_matrix = false
itdata = 0x0
#7 0x00000004000483bc in redisplay_window_1 (window=20233653)
at ../../repo/src/xdisp.c:14590
No locals.
#8 0x00000004001abd2c in internal_condition_case_1 (
bfun=0x40004837d <redisplay_window_1>, arg=20233653,
handlers=17187099827, hfun=0x4000482f2 <redisplay_window_error>)
at ../../repo/src/eval.c:1348
val = 2
c = 0xc231d0
#9 0x0000000400047595 in redisplay_internal ()
at ../../repo/src/xdisp.c:14162
mini_window = 0
mini_frame = 0x8a8e033
w = 0x134bdb0
sw = 0x134bdb0
fr = 0x400a51890 <dumped_data+3722384>
pending = false
must_finish = false
match_p = true
tlbufpos = {charpos = 0, bytepos = 376}
tlendpos = {charpos = 0, bytepos = 0}
number_of_visible_frames = 2
count = 3
sf = 0x400a51890 <dumped_data+3722384>
polling_stopped_here = false
tail = 0
frame = 17190688917
hscroll_retries = 0
consider_all_windows_p = false
update_miniwindow_p = false
#10 0x0000000400044ff0 in redisplay () at ../../repo/src/xdisp.c:13296
No locals.
#11 0x000000040010e39d in read_char (commandflag=1, map=141772755,
prev_event=0, used_mouse_menu=0xbff2df, end_time=0x0)
at ../../repo/src/keyboard.c:2482
echo_current = true
c = 0
jmpcount = 12579440
local_getcjmp = {{Part = {12578944, 17181506602}}, {Part = {
142828485, 0}}, {Part = {12578960, 17180925455}}, {Part = {
17186823872, 17180925455}}, {Part = {0, 32}}, {Part = {
12579024, 0}}, {Part = {12579024, 17180925455}}, {Part = {
17186823872, 0}}, {Part = {17189119392, 0}}, {Part = {12579072,
17180925455}}, {Part = {17186823872, 57288}}, {Part = {
12579104, 17180926156}}, {Part = {12579216, 17181642413}}, {
Part = {0, 141772739}}, {Part = {12579248, 17181465465}}, {
Part = {141772739, 0}}}
save_jump = {{Part = {12579416, 0}}, {Part = {12578512, 12579416}}, {
Part = {32, 1794720}}, {Part = {1, 8}}, {Part = {0, 0}}, {Part = {
12578768, 17180927237}}, {Part = {142828480, 6}}, {Part = {0,
0}}, {Part = {0, 142828480}}, {Part = {12578816, 17180937994}},
{Part = {142828485, 6}}, {Part = {0, 352}}, {Part = {142828480,
0}}, {Part = {12578880, 17180925455}}, {Part = {17186823872,
0}}, {Part = {0, 0}}}
tem = 141772755
save = 12579328
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = false
orig_kboard = 0xc20730
#12 0x000000040011b9e7 in read_key_sequence (keybuf=0xbff4d0, bufsize=30,
prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false)
at ../../repo/src/keyboard.c:9109
interrupted_kboard = 0xc20730
interrupted_frame = 0x400a51890 <dumped_data+3722384>
key = 142828485
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = 0
count = 3
t = 0
echo_start = 0
keys_start = 0
current_binding = 141772755
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {parent = 17188032995, map = 17188032995, start = 0, end = 0}
keytran = {parent = 17187111491, map = 17187111491, start = 0,
end = 0}
indec = {parent = 17188033011, map = 17188033011, start = 0, end = 0}
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 0
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x88363c0
fake_prefixed_keys = 0
#13 0x000000040010ba20 in command_loop_1 () at ../../repo/src/keyboard.c:1370
cmd = 488880
keybuf = {6271840, 323168, 3, 3, 0, 17182753269, 12580120, 0,
12580192, 17181633637, 4, 0, 12580192, 17180925455, 17186823872,
145721507, 17182765764, 0, 12580336, 0, 12580256, 17180925455,
17186823872, 0, 0, 2, 12580320, 17181622259, 0, 12580304}
i = 1
prev_modiff = 199
prev_buffer = 0x88363c0
already_adjusted = false
#14 0x00000004001abc72 in internal_condition_case (
bfun=0x40010b543 <command_loop_1>, handlers=23240,
hfun=0x40010ab4b <cmd_error>) at ../../repo/src/eval.c:1324
val = 149236180
c = 0xc23060
#15 0x000000040010b1d9 in command_loop_2 (ignore=0)
at ../../repo/src/keyboard.c:1112
val = 2
#16 0x00000004001ab553 in internal_catch (tag=59584,
func=0x40010b1a7 <command_loop_2>, arg=0) at ../../repo/src/eval.c:1091
val = 0
c = 0xc22ef0
#17 0x000000040010b12a in command_loop () at ../../repo/src/keyboard.c:1091
No locals.
#18 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
In GNU Emacs 26.0.50 (build 1, x86_64-w64-mingw32)
of 2017-02-23 built on DESKTOP-BFQ4DH1
Repository revision: 16efea3a883ebf633946ee9b9d0681eb55437878
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/mingw64 --with-modules
--enable-locallisppath=/c/emacs/site-lisp
CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES
Important settings:
value of $LANG: ENG
locale-coding-system: cp1252
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 19:35 bug#25875: 26.0.50; Hang logging out of MS-Windows Richard Copley
@ 2017-02-25 19:41 ` Richard Copley
2017-02-25 20:36 ` Eli Zaretskii
2017-02-25 20:33 ` Eli Zaretskii
1 sibling, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-25 19:41 UTC (permalink / raw)
To: 25875
Perhaps not a deadlock: I just ran "taskkill /im emacs.exe" and the
process woke up
and signaled a Lisp error:
Debugger entered--Lisp error: (error "Attempt to delete a surrogate
minibuffer frame")
delete-frame(#<frame *Customize Option: Package Unsigned Archives*
0000000400a51890> t)
handle-delete-frame((delete-frame (#<frame *Customize Option:
Package Unsigned Archives* 0000000400a51890>)))
dframe-handle-delete-frame((delete-frame (#<frame *Customize Option:
Package Unsigned Archives* 0000000400a51890>)))
funcall-interactively(dframe-handle-delete-frame (delete-frame
(#<frame *Customize Option: Package Unsigned Archives*
0000000400a51890>)))
call-interactively(dframe-handle-delete-frame nil [(delete-frame
(#<frame *Customize Option: Package Unsigned Archives*
0000000400a51890>))])
command-execute(dframe-handle-delete-frame nil [(delete-frame
(#<frame *Customize Option: Package Unsigned Archives*
0000000400a51890>))] t)
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 19:35 bug#25875: 26.0.50; Hang logging out of MS-Windows Richard Copley
2017-02-25 19:41 ` Richard Copley
@ 2017-02-25 20:33 ` Eli Zaretskii
2017-02-25 21:07 ` Richard Copley
1 sibling, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-25 20:33 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 25 Feb 2017 19:35:28 +0000
>
> On MS Windows, Emacs sometimes hangs when shutting down or logging out.
How did you shut it down in this case? This part:
> #2 0x0000000400266caf in sys_sleep (seconds=1000)
> at ../../repo/src/w32.c:3075
> No locals.
> #3 0x0000000400238225 in w32_wnd_proc (hwnd=0x1f076a, msg=22, wParam=1,
> lParam=0) at ../../repo/src/w32fns.c:4805
seems to indicate that you shut down your Windows session or
something?
> (This build includes 5114b3a204..: Eli Zaretskii 2017-02-23 Avoid
> quitting inside a critical section on MS-Windows, see #25279).
>
> I've included backtraces for all the threads having Emacs functions on
> the stack, because I can't tell which are deadlocked, if any. (2 and 3?)
I'm not sure I see any of them deadlocked. Each one is waiting for
something it should.
> Also got these from thread 2, frame 2.
>
> (gdb) print crit
> $1 = (CRITICAL_SECTION *) 0x401bc6a20 <crit_real>
> (gdb) print crit_real
> $2 = {DebugInfo = 0xffffffffffffffff, LockCount = -1, RecursionCount = 0,
> OwningThread = 0x0, LockSemaphore = 0x0, SpinCount = 33556432}
Any reasons why this drew your attention?
> Configured using:
> 'configure --prefix=/mingw64 --with-modules
> --enable-locallisppath=/c/emacs/site-lisp
> CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
Why are you setting _WIN32_WINNT to this value when compiling Emacs?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 19:41 ` Richard Copley
@ 2017-02-25 20:36 ` Eli Zaretskii
2017-02-25 21:13 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-25 20:36 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 25 Feb 2017 19:41:25 +0000
>
> Perhaps not a deadlock: I just ran "taskkill /im emacs.exe" and the
> process woke up
> and signaled a Lisp error:
>
> Debugger entered--Lisp error: (error "Attempt to delete a surrogate
> minibuffer frame")
> delete-frame(#<frame *Customize Option: Package Unsigned Archives*
> 0000000400a51890> t)
Is this indeed a surrogate minibuffer frame? If so, how come it's
being deleted?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 20:33 ` Eli Zaretskii
@ 2017-02-25 21:07 ` Richard Copley
2017-02-25 21:30 ` Richard Copley
2017-02-26 15:44 ` Eli Zaretskii
0 siblings, 2 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-25 21:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 25 February 2017 at 20:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 25 Feb 2017 19:35:28 +0000
>>
>> On MS Windows, Emacs sometimes hangs when shutting down or logging out.
>
> How did you shut it down in this case? This part:
>
>> #2 0x0000000400266caf in sys_sleep (seconds=1000)
>> at ../../repo/src/w32.c:3075
>> No locals.
>> #3 0x0000000400238225 in w32_wnd_proc (hwnd=0x1f076a, msg=22, wParam=1,
>> lParam=0) at ../../repo/src/w32fns.c:4805
>
> seems to indicate that you shut down your Windows session or
> something?
Yes indeed. Hence "when shutting down or logging out". In this
case shutting down the computer.
>> (This build includes 5114b3a204..: Eli Zaretskii 2017-02-23 Avoid
>> quitting inside a critical section on MS-Windows, see #25279).
>>
>> I've included backtraces for all the threads having Emacs functions on
>> the stack, because I can't tell which are deadlocked, if any. (2 and 3?)
>
> I'm not sure I see any of them deadlocked. Each one is waiting for
> something it should.
Yes, I think you're right, it wasn't a deadlock (see my later mail).
>> Also got these from thread 2, frame 2.
>>
>> (gdb) print crit
>> $1 = (CRITICAL_SECTION *) 0x401bc6a20 <crit_real>
>> (gdb) print crit_real
>> $2 = {DebugInfo = 0xffffffffffffffff, LockCount = -1, RecursionCount = 0,
>> OwningThread = 0x0, LockSemaphore = 0x0, SpinCount = 33556432}
>
> Any reasons why this drew your attention?
Labouring under a misapprehension, I thought this might be the
same sort of deadlock as in #25279, so I thought this might be
relevant. But it probably wasn't.
>> Configured using:
>> 'configure --prefix=/mingw64 --with-modules
>> --enable-locallisppath=/c/emacs/site-lisp
>> CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
>
> Why are you setting _WIN32_WINNT to this value when compiling Emacs?
It's part of a patch that sets the AppUserModelID of the Emacs
process and of the shortcut created by addpm.exe to the same
string, so that if I pin the shortcut to the taskbar, that icon
will combine with the taskbar button of a running Emacs process.
I can't imagine it's relevant to this issue.
[Would you like to see the patch? It would only be a starting point,
since it wouldn't compile on earlier versions of the OS in its
current state. And I'm still not ready to assign copyright.]
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 20:36 ` Eli Zaretskii
@ 2017-02-25 21:13 ` Richard Copley
2017-02-26 15:47 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-25 21:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 25 February 2017 at 20:36, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 25 Feb 2017 19:41:25 +0000
>>
>> Perhaps not a deadlock: I just ran "taskkill /im emacs.exe" and the
>> process woke up
>> and signaled a Lisp error:
>>
>> Debugger entered--Lisp error: (error "Attempt to delete a surrogate
>> minibuffer frame")
>> delete-frame(#<frame *Customize Option: Package Unsigned Archives*
>> 0000000400a51890> t)
>
> Is this indeed a surrogate minibuffer frame? If so, how come it's
> being deleted?
An Ediff control-panel was present. The main frame was the
surrogate minibuffer frame for the minibufferless Ediff frame. In
that situation, clicking the close button on the main frame gives
that same error.
I surmise that WM_QUERY_END_SESSION goes down the same code
path (?).
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 21:07 ` Richard Copley
@ 2017-02-25 21:30 ` Richard Copley
2017-02-25 21:37 ` Richard Copley
2017-02-26 15:44 ` Eli Zaretskii
1 sibling, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-25 21:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
>>> Configured using:
>>> 'configure --prefix=/mingw64 --with-modules
>>> --enable-locallisppath=/c/emacs/site-lisp
>>> CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
>>
>> Why are you setting _WIN32_WINNT to this value when compiling Emacs?
>
> It's part of a patch that sets the AppUserModelID of the Emacs
> process and of the shortcut created by addpm.exe to the same
> string, so that if I pin the shortcut to the taskbar, that icon
> will combine with the taskbar button of a running Emacs process.
> I can't imagine it's relevant to this issue.
>
> [Would you like to see the patch? It would only be a starting point,
> since it wouldn't compile on earlier versions of the OS in its
> current state. And I'm still not ready to assign copyright.]
Hmm, that doesn't make much sense, does it? I only need those
flags in addpm.c, not for the rest of Emacs. Perhaps it's left over
from another experiment. I've taken it out of my build script, but
I haven't rebuilt because current master doesn't build from pristine:
+ ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Checking for automake (need at least version 1.11) ... ok
Your system has the required tools.
Inferring nt/gnulib.mk from lib/gnulib.mk ...
Running 'autoreconf -fi -I m4' ...
aclocal-1.15: error: aclocal: file
'/msys64/usr/share/aclocal/xsize.m4' does not exist
autoreconf: aclocal failed with exit status: 1
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 21:30 ` Richard Copley
@ 2017-02-25 21:37 ` Richard Copley
2017-02-25 22:02 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-25 21:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 25 February 2017 at 21:30, Richard Copley <rcopley@gmail.com> wrote:
>>>> Configured using:
>>>> 'configure --prefix=/mingw64 --with-modules
>>>> --enable-locallisppath=/c/emacs/site-lisp
>>>> CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
>>>
>>> Why are you setting _WIN32_WINNT to this value when compiling Emacs?
>>
>> It's part of a patch that sets the AppUserModelID of the Emacs
>> process and of the shortcut created by addpm.exe to the same
>> string, so that if I pin the shortcut to the taskbar, that icon
>> will combine with the taskbar button of a running Emacs process.
>> I can't imagine it's relevant to this issue.
>>
>> [Would you like to see the patch? It would only be a starting point,
>> since it wouldn't compile on earlier versions of the OS in its
>> current state. And I'm still not ready to assign copyright.]
>
> Hmm, that doesn't make much sense, does it? I only need those
> flags in addpm.c, not for the rest of Emacs. Perhaps it's left over
> from another experiment. I've taken it out of my build script, but
> I haven't rebuilt because current master doesn't build from pristine:
>
> + ./autogen.sh
> Checking whether you have the necessary tools...
> (Read INSTALL.REPO for more details on building Emacs)
> Checking for autoconf (need at least version 2.65) ... ok
> Checking for automake (need at least version 1.11) ... ok
> Your system has the required tools.
> Inferring nt/gnulib.mk from lib/gnulib.mk ...
> Running 'autoreconf -fi -I m4' ...
> aclocal-1.15: error: aclocal: file
> '/msys64/usr/share/aclocal/xsize.m4' does not exist
> autoreconf: aclocal failed with exit status: 1
Please ignore that -- not sure what I did differently, but
the build is running fine now.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 21:37 ` Richard Copley
@ 2017-02-25 22:02 ` Richard Copley
2017-02-26 15:47 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-25 22:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 25 February 2017 at 21:37, Richard Copley <rcopley@gmail.com> wrote:
> On 25 February 2017 at 21:30, Richard Copley <rcopley@gmail.com> wrote:
>>>>> Configured using:
>>>>> 'configure --prefix=/mingw64 --with-modules
>>>>> --enable-locallisppath=/c/emacs/site-lisp
>>>>> CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7 'CFLAGS=-O0 -g -ggdb''
>>>>
>>>> Why are you setting _WIN32_WINNT to this value when compiling Emacs?
>>>
>>> It's part of a patch that sets the AppUserModelID of the Emacs
>>> process and of the shortcut created by addpm.exe to the same
>>> string, so that if I pin the shortcut to the taskbar, that icon
>>> will combine with the taskbar button of a running Emacs process.
>>> I can't imagine it's relevant to this issue.
>>>
>>> [Would you like to see the patch? It would only be a starting point,
>>> since it wouldn't compile on earlier versions of the OS in its
>>> current state. And I'm still not ready to assign copyright.]
>>
>> Hmm, that doesn't make much sense, does it? I only need those
>> flags in addpm.c, not for the rest of Emacs. Perhaps it's left over
>> from another experiment. I've taken it out of my build script, but
>> I haven't rebuilt because current master doesn't build from pristine:
Builds fine without that flag, so I'll stop using it. Thanks.
A negative test result: from "emacs -Q", this recipe
doesn't cause a hang:
;; open an Ediff control panel frame
M-x ediff-buffers RET *scratch* RET *Messages* RET
;; Restart the computer.
;; (Result: the computer restarts normally.)
Another data point: I observed the same thing (i.e., Windows
failing to shut down, followed by Emacs being in a state where it
doesn't respond to keyboard and mouse input) on my work Windows 7
laptop. (Didn't attach GDB and didn't try "taskkill.exe" that time.)
So this doesn't seem to be related to my hardware or Windows 10.
But it could be influenced by my config (which is all but
identical on both machines), since I haven't reproduced it
from "emacs -Q".
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 21:07 ` Richard Copley
2017-02-25 21:30 ` Richard Copley
@ 2017-02-26 15:44 ` Eli Zaretskii
2017-02-26 18:04 ` Ken Brown
1 sibling, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-26 15:44 UTC (permalink / raw)
To: Richard Copley, Ken Brown; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 25 Feb 2017 21:07:51 +0000
> Cc: 25875@debbugs.gnu.org
>
> On 25 February 2017 at 20:33, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Richard Copley <rcopley@gmail.com>
> >> Date: Sat, 25 Feb 2017 19:35:28 +0000
> >>
> >> On MS Windows, Emacs sometimes hangs when shutting down or logging out.
> >
> > How did you shut it down in this case? This part:
> >
> >> #2 0x0000000400266caf in sys_sleep (seconds=1000)
> >> at ../../repo/src/w32.c:3075
> >> No locals.
> >> #3 0x0000000400238225 in w32_wnd_proc (hwnd=0x1f076a, msg=22, wParam=1,
> >> lParam=0) at ../../repo/src/w32fns.c:4805
> >
> > seems to indicate that you shut down your Windows session or
> > something?
>
> Yes indeed. Hence "when shutting down or logging out". In this
> case shutting down the computer.
OK, supporting that is a relatively new feature, so it's little
surprise it needs more work. Ken, could you please take a look?
As I understand it, this happens because when the input thread gets
the WM_ENDSESSION message, it posts it to the main thread and goes on
to sleep for 1000 sec, to avoid ending the Emacs process before it
finishes orderly shutdown. But if the main thread happens to be
inside redisplay, it could invoke one of the function that send
messages to the input thread via SendMessage, which waits for the
input thread to respond. So we do have a kind of deadlock.
One possible idea is to use SendMessageTimeout instead, with some
suitably chosen timeout.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 21:13 ` Richard Copley
@ 2017-02-26 15:47 ` Eli Zaretskii
2017-02-26 18:26 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-26 15:47 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 25 Feb 2017 21:13:57 +0000
> Cc: 25875@debbugs.gnu.org
>
> On 25 February 2017 at 20:36, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Richard Copley <rcopley@gmail.com>
> >> Date: Sat, 25 Feb 2017 19:41:25 +0000
> >>
> >> Perhaps not a deadlock: I just ran "taskkill /im emacs.exe" and the
> >> process woke up
> >> and signaled a Lisp error:
> >>
> >> Debugger entered--Lisp error: (error "Attempt to delete a surrogate
> >> minibuffer frame")
> >> delete-frame(#<frame *Customize Option: Package Unsigned Archives*
> >> 0000000400a51890> t)
> >
> > Is this indeed a surrogate minibuffer frame? If so, how come it's
> > being deleted?
>
> An Ediff control-panel was present. The main frame was the
> surrogate minibuffer frame for the minibufferless Ediff frame. In
> that situation, clicking the close button on the main frame gives
> that same error.
I think this frame was an indirect reason for the hang.
> I surmise that WM_QUERY_END_SESSION goes down the same code
> path (?).
Hmm... I don't see WM_QUERY_END_SESSION in our sources. What am I
missing?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-25 22:02 ` Richard Copley
@ 2017-02-26 15:47 ` Eli Zaretskii
2017-02-26 18:37 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-26 15:47 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 25 Feb 2017 22:02:17 +0000
> Cc: 25875@debbugs.gnu.org
>
> A negative test result: from "emacs -Q", this recipe
> doesn't cause a hang:
>
> ;; open an Ediff control panel frame
> M-x ediff-buffers RET *scratch* RET *Messages* RET
> ;; Restart the computer.
> ;; (Result: the computer restarts normally.)
Probably because the Ediff control frame is not the selected one.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 15:44 ` Eli Zaretskii
@ 2017-02-26 18:04 ` Ken Brown
2017-02-26 18:25 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-26 18:04 UTC (permalink / raw)
To: Eli Zaretskii, Richard Copley; +Cc: 25875
On 2/26/2017 10:44 AM, Eli Zaretskii wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Yes indeed. Hence "when shutting down or logging out". In this
>> case shutting down the computer.
>
> OK, supporting that is a relatively new feature, so it's little
> surprise it needs more work. Ken, could you please take a look?
>
> As I understand it, this happens because when the input thread gets
> the WM_ENDSESSION message, it posts it to the main thread and goes on
> to sleep for 1000 sec, to avoid ending the Emacs process before it
> finishes orderly shutdown. But if the main thread happens to be
> inside redisplay, it could invoke one of the function that send
> messages to the input thread via SendMessage, which waits for the
> input thread to respond. So we do have a kind of deadlock.
The problem might be that 1000 sec is too long for the input thread to sleep. I chose that number arbitrarily, not realizing that the main thread could get stuck waiting for the input thread. What about something like this?
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -4801,8 +4801,10 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
case WM_ENDSESSION:
my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
- /* If we return, the process will be terminated immediately. */
- sleep (1000);
+ /* Allow time for Emacs to attempt an orderly shutdown. If we
+ return, the process will be terminated immediately. */
+ sleep (5);
+ return 0;
case WM_WINDOWPOSCHANGING:
/* Don't restrict the sizing of any kind of frames. If the window
With this change, I think Emacs will be killed in at most 5 seconds no matter what state it is in. But
I can't test this because I don't know how to reproduce Richard's problem.
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 18:04 ` Ken Brown
@ 2017-02-26 18:25 ` Eli Zaretskii
2017-02-26 18:58 ` Ken Brown
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-26 18:25 UTC (permalink / raw)
To: Ken Brown; +Cc: rcopley, 25875
> Cc: 25875@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 26 Feb 2017 13:04:18 -0500
>
> The problem might be that 1000 sec is too long for the input thread to sleep. I chose that number arbitrarily, not realizing that the main thread could get stuck waiting for the input thread. What about something like this?
>
> --- a/src/w32fns.c
> +++ b/src/w32fns.c
> @@ -4801,8 +4801,10 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>
> case WM_ENDSESSION:
> my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
> - /* If we return, the process will be terminated immediately. */
> - sleep (1000);
> + /* Allow time for Emacs to attempt an orderly shutdown. If we
> + return, the process will be terminated immediately. */
> + sleep (5);
> + return 0;
>
> case WM_WINDOWPOSCHANGING:
> /* Don't restrict the sizing of any kind of frames. If the window
>
> With this change, I think Emacs will be killed in at most 5 seconds no matter what state it is in. But
> I can't test this because I don't know how to reproduce Richard's problem.
I think the problem in this particular scenario is not that the input
thread sleeps too long, it's that whenever it finishes sleeping and
returns, Emacs will be killed, so the WM_ENDSESSION message that was
posted to the main thread will never have a chance to be processed,
and thus orderly shutdown will never happen.
That is why I thought about using SendMessageTimeout in the main
thread: what we really want is to cause the main thread to wake up and
process the WM_ENDSESSION message. Right?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 15:47 ` Eli Zaretskii
@ 2017-02-26 18:26 ` Richard Copley
0 siblings, 0 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-26 18:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 26 February 2017 at 15:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 25 Feb 2017 21:13:57 +0000
>> Cc: 25875@debbugs.gnu.org
>>
>> On 25 February 2017 at 20:36, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Richard Copley <rcopley@gmail.com>
>> >> Date: Sat, 25 Feb 2017 19:41:25 +0000
>> >>
>> >> Perhaps not a deadlock: I just ran "taskkill /im emacs.exe" and the
>> >> process woke up
>> >> and signaled a Lisp error:
>> >>
>> >> Debugger entered--Lisp error: (error "Attempt to delete a surrogate
>> >> minibuffer frame")
>> >> delete-frame(#<frame *Customize Option: Package Unsigned Archives*
>> >> 0000000400a51890> t)
>> >
>> > Is this indeed a surrogate minibuffer frame? If so, how come it's
>> > being deleted?
>>
>> An Ediff control-panel was present. The main frame was the
>> surrogate minibuffer frame for the minibufferless Ediff frame. In
>> that situation, clicking the close button on the main frame gives
>> that same error.
>
> I think this frame was an indirect reason for the hang.
>
>> I surmise that WM_QUERY_END_SESSION goes down the same code
>> path (?).
>
> Hmm... I don't see WM_QUERY_END_SESSION in our sources. What am I
> missing?
"surmise", v.
5 a. To form a notion that the thing in question may be so, on slight
grounds or without proof; to infer conjecturally. [OED]
In other words, just a wild guess
I hadn't properly understood your subtle reference to WM_ENDSESSION
(22) in your comment on the backtrace. By the time I did notice, I
thought I'd already bombarded you enough for one evening so I didn't
correct myself.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 15:47 ` Eli Zaretskii
@ 2017-02-26 18:37 ` Richard Copley
0 siblings, 0 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-26 18:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
On 26 February 2017 at 15:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 25 Feb 2017 22:02:17 +0000
>> Cc: 25875@debbugs.gnu.org
>>
>> A negative test result: from "emacs -Q", this recipe
>> doesn't cause a hang:
>>
>> ;; open an Ediff control panel frame
>> M-x ediff-buffers RET *scratch* RET *Messages* RET
>> ;; Restart the computer.
>> ;; (Result: the computer restarts normally.)
>
> Probably because the Ediff control frame is not the selected one.
It would have been, with that recipe.
[-- Attachment #2: Type: text/html, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 18:25 ` Eli Zaretskii
@ 2017-02-26 18:58 ` Ken Brown
2017-02-26 19:25 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-26 18:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rcopley, 25875
On 2/26/2017 1:25 PM, Eli Zaretskii wrote:
>> Cc: 25875@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 26 Feb 2017 13:04:18 -0500
>>
>> The problem might be that 1000 sec is too long for the input thread to sleep. I chose that number arbitrarily, not realizing that the main thread could get stuck waiting for the input thread. What about something like this?
>>
>> --- a/src/w32fns.c
>> +++ b/src/w32fns.c
>> @@ -4801,8 +4801,10 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>>
>> case WM_ENDSESSION:
>> my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
>> - /* If we return, the process will be terminated immediately. */
>> - sleep (1000);
>> + /* Allow time for Emacs to attempt an orderly shutdown. If we
>> + return, the process will be terminated immediately. */
>> + sleep (5);
>> + return 0;
>>
>> case WM_WINDOWPOSCHANGING:
>> /* Don't restrict the sizing of any kind of frames. If the window
>>
>> With this change, I think Emacs will be killed in at most 5 seconds no matter what state it is in. But
>> I can't test this because I don't know how to reproduce Richard's problem.
>
> I think the problem in this particular scenario is not that the input
> thread sleeps too long, it's that whenever it finishes sleeping and
> returns, Emacs will be killed, so the WM_ENDSESSION message that was
> posted to the main thread will never have a chance to be processed,
> and thus orderly shutdown will never happen.
>
> That is why I thought about using SendMessageTimeout in the main
> thread: what we really want is to cause the main thread to wake up and
> process the WM_ENDSESSION message. Right?
Yes, that would obviously be better. But in any case, I don't think we
want the input thread to sleep for 1000 seconds. If we can't arrange an
orderly shutdown, we should give up after a reasonable amount of time.
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 18:58 ` Ken Brown
@ 2017-02-26 19:25 ` Eli Zaretskii
2017-02-26 23:38 ` Ken Brown
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-26 19:25 UTC (permalink / raw)
To: Ken Brown; +Cc: rcopley, 25875
> Cc: rcopley@gmail.com, 25875@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 26 Feb 2017 13:58:23 -0500
>
> > I think the problem in this particular scenario is not that the input
> > thread sleeps too long, it's that whenever it finishes sleeping and
> > returns, Emacs will be killed, so the WM_ENDSESSION message that was
> > posted to the main thread will never have a chance to be processed,
> > and thus orderly shutdown will never happen.
> >
> > That is why I thought about using SendMessageTimeout in the main
> > thread: what we really want is to cause the main thread to wake up and
> > process the WM_ENDSESSION message. Right?
>
> Yes, that would obviously be better.
OK. Can you propose a patch that Richard could try? Or should I do
that?
> But in any case, I don't think we want the input thread to sleep for
> 1000 seconds. If we can't arrange an orderly shutdown, we should
> give up after a reasonable amount of time.
Yes, I agree.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 19:25 ` Eli Zaretskii
@ 2017-02-26 23:38 ` Ken Brown
2017-02-27 8:14 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-26 23:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rcopley, 25875
On 2/26/2017 2:25 PM, Eli Zaretskii wrote:
>> Cc: rcopley@gmail.com, 25875@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 26 Feb 2017 13:58:23 -0500
>>
>>> I think the problem in this particular scenario is not that the input
>>> thread sleeps too long, it's that whenever it finishes sleeping and
>>> returns, Emacs will be killed, so the WM_ENDSESSION message that was
>>> posted to the main thread will never have a chance to be processed,
>>> and thus orderly shutdown will never happen.
>>>
>>> That is why I thought about using SendMessageTimeout in the main
>>> thread: what we really want is to cause the main thread to wake up and
>>> process the WM_ENDSESSION message. Right?
>>
>> Yes, that would obviously be better.
>
> OK. Can you propose a patch that Richard could try?
Here's a quick and dirty attempt. If I haven't made a mistake, it
replaces every relevant call to SendMessage by a call to
SendMessageTimeout with a 100ms timeout.
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -537,6 +537,15 @@ x_update_begin (struct frame *f)
}
+#undef SendMessage
+#define SendMessage DebugSendMessage
+
+static LRESULT WINAPI
+DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
+{
+ return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
+}
+
/* Start update of window W. */
static void
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-26 23:38 ` Ken Brown
@ 2017-02-27 8:14 ` Richard Copley
2017-02-27 15:36 ` Eli Zaretskii
2017-02-27 22:37 ` Ken Brown
0 siblings, 2 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-27 8:14 UTC (permalink / raw)
To: Ken Brown; +Cc: 25875
On 26 February 2017 at 23:38, Ken Brown <kbrown@cornell.edu> wrote:
> On 2/26/2017 2:25 PM, Eli Zaretskii wrote:
>>>
>>> Cc: rcopley@gmail.com, 25875@debbugs.gnu.org
>>> From: Ken Brown <kbrown@cornell.edu>
>>> Date: Sun, 26 Feb 2017 13:58:23 -0500
>>>
>>>> I think the problem in this particular scenario is not that the input
>>>> thread sleeps too long, it's that whenever it finishes sleeping and
>>>> returns, Emacs will be killed, so the WM_ENDSESSION message that was
>>>> posted to the main thread will never have a chance to be processed,
>>>> and thus orderly shutdown will never happen.
>>>>
>>>> That is why I thought about using SendMessageTimeout in the main
>>>> thread: what we really want is to cause the main thread to wake up and
>>>> process the WM_ENDSESSION message. Right?
>>>
>>>
>>> Yes, that would obviously be better.
>>
>>
>> OK. Can you propose a patch that Richard could try?
>
>
> Here's a quick and dirty attempt. If I haven't made a mistake, it replaces
> every relevant call to SendMessage by a call to SendMessageTimeout with a
> 100ms timeout.
>
> --- a/src/w32term.c
> +++ b/src/w32term.c
> @@ -537,6 +537,15 @@ x_update_begin (struct frame *f)
> }
>
>
> +#undef SendMessage
> +#define SendMessage DebugSendMessage
> +
> +static LRESULT WINAPI
> +DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
> +{
> + return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
> +}
> +
> /* Start update of window W. */
>
> static void
>
> Ken
Sorry Ken, I can't sabotage myself like that, I have work to do.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 8:14 ` Richard Copley
@ 2017-02-27 15:36 ` Eli Zaretskii
2017-02-27 19:04 ` Richard Copley
2017-02-27 22:37 ` Ken Brown
1 sibling, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-27 15:36 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 08:14:22 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>
> > Here's a quick and dirty attempt. If I haven't made a mistake, it replaces
> > every relevant call to SendMessage by a call to SendMessageTimeout with a
> > 100ms timeout.
> >
> > --- a/src/w32term.c
> > +++ b/src/w32term.c
> > @@ -537,6 +537,15 @@ x_update_begin (struct frame *f)
> > }
> >
> >
> > +#undef SendMessage
> > +#define SendMessage DebugSendMessage
> > +
> > +static LRESULT WINAPI
> > +DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
> > +{
> > + return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
> > +}
> > +
> > /* Start update of window W. */
> >
> > static void
> >
> > Ken
>
> Sorry Ken, I can't sabotage myself like that, I have work to do.
This could be a misunderstanding: the above change is not supposed to
sabotage anything, it's supposed to be a 100% compatible change for
the current behavior when all threads are running, and also provide a
"fire escape" when the addressee of the message is for some reason
stuck, as we think happens in your scenario.
If you are unwilling to make such a sweeping change, could you at
least replace the call SendMessage in my_show_window with
SendMessageTimeoutA, using the above patch as a template?
TIA
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 15:36 ` Eli Zaretskii
@ 2017-02-27 19:04 ` Richard Copley
2017-02-27 19:16 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 19:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 27 February 2017 at 15:36, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 08:14:22 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>>
>> > Here's a quick and dirty attempt. If I haven't made a mistake, it replaces
>> > every relevant call to SendMessage by a call to SendMessageTimeout with a
>> > 100ms timeout.
>> >
>> > --- a/src/w32term.c
>> > +++ b/src/w32term.c
>> > @@ -537,6 +537,15 @@ x_update_begin (struct frame *f)
>> > }
>> >
>> >
>> > +#undef SendMessage
>> > +#define SendMessage DebugSendMessage
>> > +
>> > +static LRESULT WINAPI
>> > +DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
>> > +{
>> > + return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
>> > +}
>> > +
>> > /* Start update of window W. */
>> >
>> > static void
>> >
>> > Ken
>>
>> Sorry Ken, I can't sabotage myself like that, I have work to do.
>
> This could be a misunderstanding: the above change is not supposed to
> sabotage anything, it's supposed to be a 100% compatible change for
> the current behavior when all threads are running, and also provide a
> "fire escape" when the addressee of the message is for some reason
> stuck, as we think happens in your scenario.
From the docs for SendMessageTimeout:
"If the function succeeds, the return value is nonzero.".
We're going to cast that to HWND and pretend it's a scrollbar?
(See `my_create_vscrollbar()' in "w32term.c".)
Then what happens? Ken, what happened when you tested this?
> If you are unwilling to make such a sweeping change, could you at
> least replace the call SendMessage in my_show_window with
> SendMessageTimeoutA, using the above patch as a template?
I will think about it, but I'll ignore the patch :)
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:04 ` Richard Copley
@ 2017-02-27 19:16 ` Eli Zaretskii
2017-02-27 19:23 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-27 19:16 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 19:04:23 +0000
> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>
> >> > +static LRESULT WINAPI
> >> > +DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
> >> > +{
> >> > + return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
> >> > +}
> >> > +
> >> > /* Start update of window W. */
> >> >
> >> > static void
> >> >
> >> > Ken
> >>
> >> Sorry Ken, I can't sabotage myself like that, I have work to do.
> >
> > This could be a misunderstanding: the above change is not supposed to
> > sabotage anything, it's supposed to be a 100% compatible change for
> > the current behavior when all threads are running, and also provide a
> > "fire escape" when the addressee of the message is for some reason
> > stuck, as we think happens in your scenario.
>
> >From the docs for SendMessageTimeout:
> "If the function succeeds, the return value is nonzero.".
> We're going to cast that to HWND and pretend it's a scrollbar?
No, the result is returned in the last argument of SendMessageTimeout
(which shouldn't be NULL for getting hold of that, of course).
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:16 ` Eli Zaretskii
@ 2017-02-27 19:23 ` Richard Copley
2017-02-27 19:30 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 19:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 27 February 2017 at 19:16, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 19:04:23 +0000
>> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>>
>> >> > +static LRESULT WINAPI
>> >> > +DebugSendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
>> >> > +{
>> >> > + return SendMessageTimeoutA (hWnd, Msg, wParam, lParam, 0, 100, NULL);
>> >> > +}
>> >> > +
>> >> > /* Start update of window W. */
>> >> >
>> >> > static void
>> >> >
>> >> > Ken
>> >>
>> >> Sorry Ken, I can't sabotage myself like that, I have work to do.
>> >
>> > This could be a misunderstanding: the above change is not supposed to
>> > sabotage anything, it's supposed to be a 100% compatible change for
>> > the current behavior when all threads are running, and also provide a
>> > "fire escape" when the addressee of the message is for some reason
>> > stuck, as we think happens in your scenario.
>>
>> >From the docs for SendMessageTimeout:
>> "If the function succeeds, the return value is nonzero.".
>> We're going to cast that to HWND and pretend it's a scrollbar?
>
> No, the result is returned in the last argument of SendMessageTimeout
> (which shouldn't be NULL for getting hold of that, of course).
My point exactly.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:23 ` Richard Copley
@ 2017-02-27 19:30 ` Richard Copley
2017-02-27 19:39 ` Ken Brown
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 19:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
If you want to block or delay a shutdown in recent
Windows versions you need to use
ShutdownBlockReasonCreate (it's unfortunate, but
we lazy programmers proved we couldn't be trusted,
collectively, to handle WM_QUERY_ENDSESSION
correctly, so the arms race had to be escalated in
order to allow users to shut down their computers
reliably).
Ken, what was the original change intended to guard
against? What would people be doing with Emacs that
can't simply be abandoned? Did you have a particular
example in mind?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:30 ` Richard Copley
@ 2017-02-27 19:39 ` Ken Brown
2017-02-27 19:46 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-27 19:39 UTC (permalink / raw)
To: Richard Copley, Eli Zaretskii; +Cc: 25875
On 2/27/2017 2:30 PM, Richard Copley wrote:
> If you want to block or delay a shutdown in recent
> Windows versions you need to use
> ShutdownBlockReasonCreate (it's unfortunate, but
> we lazy programmers proved we couldn't be trusted,
> collectively, to handle WM_QUERY_ENDSESSION
> correctly, so the arms race had to be escalated in
> order to allow users to shut down their computers
> reliably).
In spite of the careless mistake in my patch, you could still test Eli's
suggestion of using SendMessageTimeout instead of SendMessage, at least
in my_show_window.
> Ken, what was the original change intended to guard
> against? What would people be doing with Emacs that
> can't simply be abandoned? Did you have a particular
> example in mind?
Bug#23483.
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:39 ` Ken Brown
@ 2017-02-27 19:46 ` Richard Copley
2017-02-27 19:56 ` Richard Copley
2017-02-27 20:27 ` Eli Zaretskii
0 siblings, 2 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-27 19:46 UTC (permalink / raw)
To: Ken Brown; +Cc: 25875
On 27 February 2017 at 19:39, Ken Brown <kbrown@cornell.edu> wrote:
> On 2/27/2017 2:30 PM, Richard Copley wrote:
>>
>> If you want to block or delay a shutdown in recent
>> Windows versions you need to use
>> ShutdownBlockReasonCreate (it's unfortunate, but
>> we lazy programmers proved we couldn't be trusted,
>> collectively, to handle WM_QUERY_ENDSESSION
>> correctly, so the arms race had to be escalated in
>> order to allow users to shut down their computers
>> reliably).
>
>
> In spite of the careless mistake in my patch, you could still test Eli's
> suggestion of using SendMessageTimeout instead of SendMessage, at least in
> my_show_window.
I can't, not really. Remember, I don't have a recipe.
I'll never be able to observe whether it's working or not.
(Am I missing something?)
>> Ken, what was the original change intended to guard
>> against? What would people be doing with Emacs that
>> can't simply be abandoned? Did you have a particular
>> example in mind?
>
>
> Bug#23483.
That's not a real issue, in my opinion. It's already covered,
by autosave.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:46 ` Richard Copley
@ 2017-02-27 19:56 ` Richard Copley
2017-02-27 20:19 ` Ken Brown
2017-02-27 20:27 ` Eli Zaretskii
1 sibling, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 19:56 UTC (permalink / raw)
To: Ken Brown; +Cc: 25875
On 27 February 2017 at 19:46, Richard Copley <rcopley@gmail.com> wrote:
> On 27 February 2017 at 19:39, Ken Brown <kbrown@cornell.edu> wrote:
>> On 2/27/2017 2:30 PM, Richard Copley wrote:
>>>
>>> If you want to block or delay a shutdown in recent
>>> Windows versions you need to use
>>> ShutdownBlockReasonCreate (it's unfortunate, but
>>> we lazy programmers proved we couldn't be trusted,
>>> collectively, to handle WM_QUERY_ENDSESSION
>>> correctly, so the arms race had to be escalated in
>>> order to allow users to shut down their computers
>>> reliably).
>>
>>
>> In spite of the careless mistake in my patch, you could still test Eli's
>> suggestion of using SendMessageTimeout instead of SendMessage, at least in
>> my_show_window.
>
> I can't, not really. Remember, I don't have a recipe.
> I'll never be able to observe whether it's working or not.
> (Am I missing something?)
>
>>> Ken, what was the original change intended to guard
>>> against? What would people be doing with Emacs that
>>> can't simply be abandoned? Did you have a particular
>>> example in mind?
>>
>>
>> Bug#23483.
>
> That's not a real issue, in my opinion. It's already covered,
> by autosave.
There are programs like the OP in #23483 described, which
interrupt a shutdown to ask the user whether to save. Some of
them even call themselves "programmers' text editors" (shudder).
Emacs autosave is and always has been a better solution.
You can shoot yourself in the foot by making small but important
changes and then immediately shutting down Windows. But you'd
almost have to be doing it on purpose.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:56 ` Richard Copley
@ 2017-02-27 20:19 ` Ken Brown
0 siblings, 0 replies; 43+ messages in thread
From: Ken Brown @ 2017-02-27 20:19 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
On 2/27/2017 2:56 PM, Richard Copley wrote:
> On 27 February 2017 at 19:46, Richard Copley <rcopley@gmail.com> wrote:
>> On 27 February 2017 at 19:39, Ken Brown <kbrown@cornell.edu> wrote:
>>> On 2/27/2017 2:30 PM, Richard Copley wrote:
>>>>
>>>> If you want to block or delay a shutdown in recent
>>>> Windows versions you need to use
>>>> ShutdownBlockReasonCreate (it's unfortunate, but
>>>> we lazy programmers proved we couldn't be trusted,
>>>> collectively, to handle WM_QUERY_ENDSESSION
>>>> correctly, so the arms race had to be escalated in
>>>> order to allow users to shut down their computers
>>>> reliably).
>>>
>>>
>>> In spite of the careless mistake in my patch, you could still test Eli's
>>> suggestion of using SendMessageTimeout instead of SendMessage, at least in
>>> my_show_window.
>>
>> I can't, not really. Remember, I don't have a recipe.
>> I'll never be able to observe whether it's working or not.
>> (Am I missing something?)
>>
>>>> Ken, what was the original change intended to guard
>>>> against? What would people be doing with Emacs that
>>>> can't simply be abandoned? Did you have a particular
>>>> example in mind?
>>>
>>>
>>> Bug#23483.
>>
>> That's not a real issue, in my opinion. It's already covered,
>> by autosave.
No, it isn't covered. We don't know that the auto-save files are
up-to-date at the time of shutdown.
> There are programs like the OP in #23483 described, which
> interrupt a shutdown to ask the user whether to save. Some of
> them even call themselves "programmers' text editors" (shudder).
> Emacs autosave is and always has been a better solution.
> You can shoot yourself in the foot by making small but important
> changes and then immediately shutting down Windows. But you'd
> almost have to be doing it on purpose.
I think it's reasonable for Emacs to attempt an orderly shutdown when
the system is being shutdown, rather than just allowing the system to
kill it. You've found a bug in my implementation of this, and I'm happy
to try to fix it.
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 19:46 ` Richard Copley
2017-02-27 19:56 ` Richard Copley
@ 2017-02-27 20:27 ` Eli Zaretskii
2017-02-27 20:52 ` Richard Copley
1 sibling, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-27 20:27 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 19:46:21 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>
> > Bug#23483.
>
> That's not a real issue, in my opinion. It's already covered,
> by autosave.
I don't think it is, because when WM_ENDSESSION comes in, Emacs will
be terminated without giving it a chance to auto-save.
Ken's change was meant to delay the shutdown long enough for Emacs to
exit in an orderly fashion. The idea of the design is correct, IMO,
it's just that we should avoid the hang.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 20:27 ` Eli Zaretskii
@ 2017-02-27 20:52 ` Richard Copley
2017-02-27 20:58 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 20:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 27 February 2017 at 20:27, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 19:46:21 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>>
>> > Bug#23483.
>>
>> That's not a real issue, in my opinion. It's already covered,
>> by autosave.
>
> I don't think it is, because when WM_ENDSESSION comes in, Emacs will
> be terminated without giving it a chance to auto-save.
>
> Ken's change was meant to delay the shutdown long enough for Emacs to
> exit in an orderly fashion. The idea of the design is correct, IMO,
> it's just that we should avoid the hang.
OK. I don't mean to be difficult, I just don't see what testing I can do
that would be of any use.
Eli, you said:
> As I understand it, this happens because when the input thread gets
> the WM_ENDSESSION message, it posts it to the main thread and goes on
> to sleep for 1000 sec, to avoid ending the Emacs process before it
> finishes orderly shutdown. But if the main thread happens to be
> inside redisplay, it could invoke one of the function that send
> messages to the input thread via SendMessage, which waits for the
> input thread to respond. So we do have a kind of deadlock.
Posting a message and then sleeping while it's processed is odd,
isn't it? If the input thread /sent/ its message to the main thread,
then while waiting for SendMessage to return, the input thread would
automatically continue to process sent messages
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 20:52 ` Richard Copley
@ 2017-02-27 20:58 ` Eli Zaretskii
2017-02-27 21:09 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-27 20:58 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 20:52:16 +0000
> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>
> Eli, you said:
>
> > As I understand it, this happens because when the input thread gets
> > the WM_ENDSESSION message, it posts it to the main thread and goes on
> > to sleep for 1000 sec, to avoid ending the Emacs process before it
> > finishes orderly shutdown. But if the main thread happens to be
> > inside redisplay, it could invoke one of the function that send
> > messages to the input thread via SendMessage, which waits for the
> > input thread to respond. So we do have a kind of deadlock.
>
> Posting a message and then sleeping while it's processed is odd,
> isn't it? If the input thread /sent/ its message to the main thread,
> then while waiting for SendMessage to return, the input thread would
> automatically continue to process sent messages
No, it's the main thread that calls SendMessage, to tell the input
thread to draw something. And since the input thread is inside
'sleep', the SendMessage call never returns, and the main thread never
gets around to checking its input queue, where there's an event bound
to kill-emacs, waiting to be processed.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 20:58 ` Eli Zaretskii
@ 2017-02-27 21:09 ` Richard Copley
2017-02-28 3:30 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 21:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 27 February 2017 at 20:58, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 20:52:16 +0000
>> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>>
>> Eli, you said:
>>
>> > As I understand it, this happens because when the input thread gets
>> > the WM_ENDSESSION message, it posts it to the main thread and goes on
>> > to sleep for 1000 sec, to avoid ending the Emacs process before it
>> > finishes orderly shutdown. But if the main thread happens to be
>> > inside redisplay, it could invoke one of the function that send
>> > messages to the input thread via SendMessage, which waits for the
>> > input thread to respond. So we do have a kind of deadlock.
>>
>> Posting a message and then sleeping while it's processed is odd,
>> isn't it? If the input thread /sent/ its message to the main thread,
>> then while waiting for SendMessage to return, the input thread would
>> automatically continue to process sent messages
>
> No, it's the main thread that calls SendMessage, to tell the input
> thread to draw something. And since the input thread is inside
> 'sleep', the SendMessage call never returns, and the main thread never
> gets around to checking its input queue, where there's an event bound
> to kill-emacs, waiting to be processed.
Please Eli, read what I said again. It might not be right, but you
misunderstood it.
I know the input thread isn't calling SendMessage. It's callling PostMessage and
then sleep. I'm suggesting that the input thread should call SendMessage.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 8:14 ` Richard Copley
2017-02-27 15:36 ` Eli Zaretskii
@ 2017-02-27 22:37 ` Ken Brown
2017-02-27 23:03 ` Richard Copley
1 sibling, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-27 22:37 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On 2/27/2017 3:14 AM, Richard Copley wrote:
> Sorry Ken, I can't sabotage myself like that, I have work to do.
FWIW, I'm attaching a corrected version of the patch. With one
exception, it only replaces SendMessage by SendMessageTimeout in cases
where the return value of SendMessage was not used. In the exceptional
case, the return value was only tested to see if it was 0 or not, so I
think the replacement is still correct.
Richard, it's your call whether or not it's worthwhile for you to run
with this patch for a while and see what happens. I understand that
this might not give a definitive answer.
I still want to eventually apply the patch I posted in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25875#41, which I think
will solve the problem in a less satisfactory way. But I'd rather hold
off on that in the hope that we'll get some evidence as to whether we've
correctly diagnosed the problem.
Ken
[-- Attachment #2: SendMessageTimeout.patch --]
[-- Type: text/plain, Size: 3087 bytes --]
diff --git a/src/w32term.c b/src/w32term.c
index d6b78fd..ba646fb 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -548,7 +548,8 @@ x_update_window_begin (struct window *w)
/* Hide the system caret during an update. */
if (w32_use_visible_system_caret && w32_system_caret_hwnd)
{
- SendMessage (w32_system_caret_hwnd, WM_EMACS_HIDE_CARET, 0, 0);
+ SendMessageTimeout (w32_system_caret_hwnd, WM_EMACS_HIDE_CARET, 0, 0,
+ 0, 100, NULL);
}
w->output_cursor = w->cursor;
@@ -714,7 +715,8 @@ x_update_window_end (struct window *w, bool cursor_on_p,
x_update_window_begin. */
if (w32_use_visible_system_caret && w32_system_caret_hwnd)
{
- SendMessage (w32_system_caret_hwnd, WM_EMACS_SHOW_CARET, 0, 0);
+ SendMessageTimeout (w32_system_caret_hwnd, WM_EMACS_SHOW_CARET, 0, 0,
+ 0, 100, NULL);
}
}
@@ -3668,8 +3670,8 @@ static BOOL
my_show_window (struct frame *f, HWND hwnd, int how)
{
#ifndef ATTACH_THREADS
- return SendMessage (FRAME_W32_WINDOW (f), WM_EMACS_SHOWWINDOW,
- (WPARAM) hwnd, (LPARAM) how);
+ return SendMessageTimeout (FRAME_W32_WINDOW (f), WM_EMACS_SHOWWINDOW,
+ (WPARAM) hwnd, (LPARAM) how, 0, 100, NULL);
#else
return ShowWindow (hwnd, how);
#endif
@@ -3687,7 +3689,8 @@ my_set_window_pos (HWND hwnd, HWND hwndAfter,
pos.cx = cx;
pos.cy = cy;
pos.flags = flags;
- SendMessage (hwnd, WM_EMACS_SETWINDOWPOS, (WPARAM) &pos, 0);
+ SendMessageTimeout (hwnd, WM_EMACS_SETWINDOWPOS, (WPARAM) &pos, 0,
+ 0, 100, NULL);
#else
SetWindowPos (hwnd, hwndAfter, x, y, cx, cy, flags);
#endif
@@ -3697,29 +3700,31 @@ my_set_window_pos (HWND hwnd, HWND hwndAfter,
static void
my_set_focus (struct frame * f, HWND hwnd)
{
- SendMessage (FRAME_W32_WINDOW (f), WM_EMACS_SETFOCUS,
- (WPARAM) hwnd, 0);
+ SendMessageTimeout (FRAME_W32_WINDOW (f), WM_EMACS_SETFOCUS,
+ (WPARAM) hwnd, 0, 0, 100, NULL);
}
#endif
static void
my_set_foreground_window (HWND hwnd)
{
- SendMessage (hwnd, WM_EMACS_SETFOREGROUND, (WPARAM) hwnd, 0);
+ SendMessageTimeout (hwnd, WM_EMACS_SETFOREGROUND, (WPARAM) hwnd, 0,
+ 0, 100, NULL);
}
static void
my_destroy_window (struct frame * f, HWND hwnd)
{
- SendMessage (FRAME_W32_WINDOW (f), WM_EMACS_DESTROYWINDOW,
- (WPARAM) hwnd, 0);
+ SendMessageTimeout (FRAME_W32_WINDOW (f), WM_EMACS_DESTROYWINDOW,
+ (WPARAM) hwnd, 0, 0, 100, NULL);
}
static void
my_bring_window_to_top (HWND hwnd)
{
- SendMessage (hwnd, WM_EMACS_BRINGTOTOP, (WPARAM) hwnd, 0);
+ SendMessageTimeout (hwnd, WM_EMACS_BRINGTOTOP, (WPARAM) hwnd, 0,
+ 0, 100, NULL);
}
/* Create a scroll bar and return the scroll bar vector for it. W is
@@ -6538,7 +6543,8 @@ x_iconify_frame (struct frame *f)
x_set_bitmap_icon (f);
/* Simulate the user minimizing the frame. */
- SendMessage (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, SC_MINIMIZE, 0);
+ SendMessageTimeout (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, SC_MINIMIZE, 0,
+ 0, 100, NULL);
SET_FRAME_VISIBLE (f, 0);
SET_FRAME_ICONIFIED (f, true);
^ permalink raw reply related [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 22:37 ` Ken Brown
@ 2017-02-27 23:03 ` Richard Copley
2017-02-28 3:35 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-27 23:03 UTC (permalink / raw)
To: Ken Brown; +Cc: 25875
On 27 February 2017 at 22:37, Ken Brown <kbrown@cornell.edu> wrote:
> On 2/27/2017 3:14 AM, Richard Copley wrote:
>>
>> Sorry Ken, I can't sabotage myself like that, I have work to do.
>
>
> FWIW, I'm attaching a corrected version of the patch. With one exception,
> it only replaces SendMessage by SendMessageTimeout in cases where the return
> value of SendMessage was not used. In the exceptional case, the return
> value was only tested to see if it was 0 or not, so I think the replacement
> is still correct.
>
> Richard, it's your call whether or not it's worthwhile for you to run with
> this patch for a while and see what happens. I understand that this might
> not give a definitive answer.
>
> I still want to eventually apply the patch I posted in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25875#41, which I think will
> solve the problem in a less satisfactory way. But I'd rather hold off on
> that in the hope that we'll get some evidence as to whether we've correctly
> diagnosed the problem.
Please imagine: I report back after a week (or two, or four) and tell
you that Emacs didn't prevent any Windows shutdowns. In that time
I might have attempted to shut down Windows a handful of times.
Will you have learned anything, anything at all?
If the answer is yes, I'll be happy to help. Otherwise I'd just be
wasting your time.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 21:09 ` Richard Copley
@ 2017-02-28 3:30 ` Eli Zaretskii
2017-02-28 6:37 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-28 3:30 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 21:09:52 +0000
> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>
> >> Posting a message and then sleeping while it's processed is odd,
> >> isn't it? If the input thread /sent/ its message to the main thread,
> >> then while waiting for SendMessage to return, the input thread would
> >> automatically continue to process sent messages
> >
> > No, it's the main thread that calls SendMessage, to tell the input
> > thread to draw something. And since the input thread is inside
> > 'sleep', the SendMessage call never returns, and the main thread never
> > gets around to checking its input queue, where there's an event bound
> > to kill-emacs, waiting to be processed.
>
> Please Eli, read what I said again. It might not be right, but you
> misunderstood it.
> I know the input thread isn't calling SendMessage. It's callling PostMessage and
> then sleep. I'm suggesting that the input thread should call SendMessage.
The input thread doesn't call PostMessage. It calls post_message,
which is a private messaging mechanism between the input thread and
the main thread, implemented in w32xfns.c and based on a critical
section. IOW, we don't use the Windows messaging in that case. So I
don't see how calling SendMessage will help in this situation. Am I
missing something?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-27 23:03 ` Richard Copley
@ 2017-02-28 3:35 ` Eli Zaretskii
2017-02-28 7:21 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-28 3:35 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 27 Feb 2017 23:03:26 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>
> Please imagine: I report back after a week (or two, or four) and tell
> you that Emacs didn't prevent any Windows shutdowns. In that time
> I might have attempted to shut down Windows a handful of times.
>
> Will you have learned anything, anything at all?
How representative would the above sample be, relative to the
frequency of the problem you see when shutting down Windows? If you
see such problems almost every shutdown, then yes, we'd be learning a
lot.
Thanks.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 3:30 ` Eli Zaretskii
@ 2017-02-28 6:37 ` Richard Copley
0 siblings, 0 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-28 6:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 28 February 2017 at 03:30, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 21:09:52 +0000
>> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>>
>> >> Posting a message and then sleeping while it's processed is odd,
>> >> isn't it? If the input thread /sent/ its message to the main thread,
>> >> then while waiting for SendMessage to return, the input thread would
>> >> automatically continue to process sent messages
>> >
>> > No, it's the main thread that calls SendMessage, to tell the input
>> > thread to draw something. And since the input thread is inside
>> > 'sleep', the SendMessage call never returns, and the main thread never
>> > gets around to checking its input queue, where there's an event bound
>> > to kill-emacs, waiting to be processed.
>>
>> Please Eli, read what I said again. It might not be right, but you
>> misunderstood it.
>> I know the input thread isn't calling SendMessage. It's callling PostMessage and
>> then sleep. I'm suggesting that the input thread should call SendMessage.
>
> The input thread doesn't call PostMessage. It calls post_message,
> which is a private messaging mechanism between the input thread and
> the main thread, implemented in w32xfns.c and based on a critical
> section. IOW, we don't use the Windows messaging in that case. So I
> don't see how calling SendMessage will help in this situation. Am I
> missing something?
I see, thanks.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 3:35 ` Eli Zaretskii
@ 2017-02-28 7:21 ` Richard Copley
2017-02-28 15:36 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Richard Copley @ 2017-02-28 7:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 28 February 2017 at 03:35, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 27 Feb 2017 23:03:26 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, 25875@debbugs.gnu.org
>>
>> Please imagine: I report back after a week (or two, or four) and tell
>> you that Emacs didn't prevent any Windows shutdowns. In that time
>> I might have attempted to shut down Windows a handful of times.
>>
>> Will you have learned anything, anything at all?
>
> How representative would the above sample be, relative to the
> frequency of the problem you see when shutting down Windows? If you
> see such problems almost every shutdown, then yes, we'd be learning a
> lot.
In the nine months since Ken's change, I've noticed a problem with
Emacs twice.
Ken, Eli, are you going to be running Emacs with that patch installed?
I can't get my head around the idea. If we don't care whether or not
the action in question has finished when SendMessage returns,
then why are we using SendMessage? And if we do care, then
shouldn't I expect weird bugs caused by timing out when the system's
under load?
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 7:21 ` Richard Copley
@ 2017-02-28 15:36 ` Eli Zaretskii
2017-02-28 16:40 ` Ken Brown
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-28 15:36 UTC (permalink / raw)
To: Richard Copley; +Cc: 25875
> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 28 Feb 2017 07:21:04 +0000
> Cc: Ken Brown <kbrown@cornell.edu>, 25875@debbugs.gnu.org
>
> > How representative would the above sample be, relative to the
> > frequency of the problem you see when shutting down Windows? If you
> > see such problems almost every shutdown, then yes, we'd be learning a
> > lot.
>
> In the nine months since Ken's change, I've noticed a problem with
> Emacs twice.
Then I guess it would be better to just push those changes and see if
they do any harm.
> Ken, Eli, are you going to be running Emacs with that patch installed?
I never use the master branch for serious work, so it doesn't matter
what I do. In addition, I almost never shut down my systems.
> I can't get my head around the idea. If we don't care whether or not
> the action in question has finished when SendMessage returns,
> then why are we using SendMessage? And if we do care, then
> shouldn't I expect weird bugs caused by timing out when the system's
> under load?
If a window procedure doesn't process messages for more than 5 sec,
Windows will put "Not Responding" on its caption bar. So I think the
100 msec number in Ken's patch should be changed to something like
6000, and then we are fine, because even on a busy system this should
be long enough. And if Emacs (and the OS) is about to shut down, it's
even less of a problem to ignore a message that timed out, IMO.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 15:36 ` Eli Zaretskii
@ 2017-02-28 16:40 ` Ken Brown
2017-02-28 16:44 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brown @ 2017-02-28 16:40 UTC (permalink / raw)
To: Eli Zaretskii, Richard Copley; +Cc: 25875-done
On 2/28/2017 10:36 AM, Eli Zaretskii wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> In the nine months since Ken's change, I've noticed a problem with
>> Emacs twice.
>
> Then I guess it would be better to just push those changes and see if
> they do any harm.
>> I can't get my head around the idea. If we don't care whether or not
>> the action in question has finished when SendMessage returns,
>> then why are we using SendMessage? And if we do care, then
>> shouldn't I expect weird bugs caused by timing out when the system's
>> under load?
>
> If a window procedure doesn't process messages for more than 5 sec,
> Windows will put "Not Responding" on its caption bar. So I think the
> 100 msec number in Ken's patch should be changed to something like
> 6000, and then we are fine, because even on a busy system this should
> be long enough. And if Emacs (and the OS) is about to shut down, it's
> even less of a problem to ignore a message that timed out, IMO.
I've pushed the patch (with 6000 msec) and am closing the bug. Richard,
please reopen if you ever see the problem again.
I'm leaving the sleep(1000) in w32_wnd_proc, at least for now, because I
want to find out about it if the problem isn't really fixed. Maybe I'll
add a FIXME comment.
Ken
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 16:40 ` Ken Brown
@ 2017-02-28 16:44 ` Eli Zaretskii
2017-02-28 18:59 ` Richard Copley
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2017-02-28 16:44 UTC (permalink / raw)
To: Ken Brown; +Cc: rcopley, 25875
> Cc: 25875-done@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Tue, 28 Feb 2017 11:40:05 -0500
>
> I've pushed the patch (with 6000 msec) and am closing the bug.
Thanks.
^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#25875: 26.0.50; Hang logging out of MS-Windows
2017-02-28 16:44 ` Eli Zaretskii
@ 2017-02-28 18:59 ` Richard Copley
0 siblings, 0 replies; 43+ messages in thread
From: Richard Copley @ 2017-02-28 18:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25875
On 28 February 2017 at 16:44, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: 25875-done@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Tue, 28 Feb 2017 11:40:05 -0500
>>
>> I've pushed the patch (with 6000 msec) and am closing the bug.
>
> Thanks.
Thank you both.
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2017-02-28 18:59 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-25 19:35 bug#25875: 26.0.50; Hang logging out of MS-Windows Richard Copley
2017-02-25 19:41 ` Richard Copley
2017-02-25 20:36 ` Eli Zaretskii
2017-02-25 21:13 ` Richard Copley
2017-02-26 15:47 ` Eli Zaretskii
2017-02-26 18:26 ` Richard Copley
2017-02-25 20:33 ` Eli Zaretskii
2017-02-25 21:07 ` Richard Copley
2017-02-25 21:30 ` Richard Copley
2017-02-25 21:37 ` Richard Copley
2017-02-25 22:02 ` Richard Copley
2017-02-26 15:47 ` Eli Zaretskii
2017-02-26 18:37 ` Richard Copley
2017-02-26 15:44 ` Eli Zaretskii
2017-02-26 18:04 ` Ken Brown
2017-02-26 18:25 ` Eli Zaretskii
2017-02-26 18:58 ` Ken Brown
2017-02-26 19:25 ` Eli Zaretskii
2017-02-26 23:38 ` Ken Brown
2017-02-27 8:14 ` Richard Copley
2017-02-27 15:36 ` Eli Zaretskii
2017-02-27 19:04 ` Richard Copley
2017-02-27 19:16 ` Eli Zaretskii
2017-02-27 19:23 ` Richard Copley
2017-02-27 19:30 ` Richard Copley
2017-02-27 19:39 ` Ken Brown
2017-02-27 19:46 ` Richard Copley
2017-02-27 19:56 ` Richard Copley
2017-02-27 20:19 ` Ken Brown
2017-02-27 20:27 ` Eli Zaretskii
2017-02-27 20:52 ` Richard Copley
2017-02-27 20:58 ` Eli Zaretskii
2017-02-27 21:09 ` Richard Copley
2017-02-28 3:30 ` Eli Zaretskii
2017-02-28 6:37 ` Richard Copley
2017-02-27 22:37 ` Ken Brown
2017-02-27 23:03 ` Richard Copley
2017-02-28 3:35 ` Eli Zaretskii
2017-02-28 7:21 ` Richard Copley
2017-02-28 15:36 ` Eli Zaretskii
2017-02-28 16:40 ` Ken Brown
2017-02-28 16:44 ` Eli Zaretskii
2017-02-28 18:59 ` Richard Copley
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).