Package: emacs;
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Sat, 25 Feb 2017 19:37:01 UTC
Severity: normal
Found in version 26.0.50
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25875 in the body.
You can then email your comments to 25875 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 19:37:01 GMT) Full text and rfc822 format available.Richard Copley <rcopley <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Sat, 25 Feb 2017 19:37:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org> Subject: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 19:35:28 +0000
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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 19:43:01 GMT) Full text and rfc822 format available.Message #8 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: 25875 <at> debbugs.gnu.org Subject: Re: 26.0.50; Hang logging out of MS-Windows 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) 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)
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 20:35:02 GMT) Full text and rfc822 format available.Message #11 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 22:33:20 +0200
> From: Richard Copley <rcopley <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 20:37:01 GMT) Full text and rfc822 format available.Message #14 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 22:36:13 +0200
> From: Richard Copley <rcopley <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 21:09:01 GMT) Full text and rfc822 format available.Message #17 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 21:07:51 +0000
On 25 February 2017 at 20:33, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Richard Copley <rcopley <at> 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.]
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 21:15:02 GMT) Full text and rfc822 format available.Message #20 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 21:13:57 +0000
On 25 February 2017 at 20:36, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> 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 (?).
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 21:32:02 GMT) Full text and rfc822 format available.Message #23 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 21:30:55 +0000
>>> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 21:38:01 GMT) Full text and rfc822 format available.Message #26 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 21:37:10 +0000
On 25 February 2017 at 21:30, Richard Copley <rcopley <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sat, 25 Feb 2017 22:03:02 GMT) Full text and rfc822 format available.Message #29 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sat, 25 Feb 2017 22:02:17 +0000
On 25 February 2017 at 21:37, Richard Copley <rcopley <at> gmail.com> wrote: > On 25 February 2017 at 21:30, Richard Copley <rcopley <at> 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".
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 15:46:02 GMT) Full text and rfc822 format available.Message #32 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com>, Ken Brown <kbrown <at> cornell.edu> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 17:44:51 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Sat, 25 Feb 2017 21:07:51 +0000 > Cc: 25875 <at> debbugs.gnu.org > > On 25 February 2017 at 20:33, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Richard Copley <rcopley <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 15:48:02 GMT) Full text and rfc822 format available.Message #35 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 17:47:03 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Sat, 25 Feb 2017 21:13:57 +0000 > Cc: 25875 <at> debbugs.gnu.org > > On 25 February 2017 at 20:36, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> From: Richard Copley <rcopley <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 15:49:01 GMT) Full text and rfc822 format available.Message #38 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 17:47:48 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Sat, 25 Feb 2017 22:02:17 +0000 > Cc: 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 18:05:01 GMT) Full text and rfc822 format available.Message #41 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Eli Zaretskii <eliz <at> gnu.org>, Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 13:04:18 -0500
On 2/26/2017 10:44 AM, Eli Zaretskii wrote:
>> From: Richard Copley <rcopley <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 18:27:02 GMT) Full text and rfc822 format available.Message #44 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Brown <kbrown <at> cornell.edu> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 20:25:33 +0200
> Cc: 25875 <at> debbugs.gnu.org > From: Ken Brown <kbrown <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 18:28:01 GMT) Full text and rfc822 format available.Message #47 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 18:26:49 +0000
On 26 February 2017 at 15:47, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Sat, 25 Feb 2017 21:13:57 +0000 >> Cc: 25875 <at> debbugs.gnu.org >> >> On 25 February 2017 at 20:36, Eli Zaretskii <eliz <at> gnu.org> wrote: >> >> From: Richard Copley <rcopley <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 18:38:01 GMT) Full text and rfc822 format available.Message #50 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 18:37:41 +0000
[Message part 1 (text/plain, inline)]
On 26 February 2017 at 15:47, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Sat, 25 Feb 2017 22:02:17 +0000 >> Cc: 25875 <at> 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.
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 18:59:02 GMT) Full text and rfc822 format available.Message #53 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 13:58:23 -0500
On 2/26/2017 1:25 PM, Eli Zaretskii wrote: >> Cc: 25875 <at> debbugs.gnu.org >> From: Ken Brown <kbrown <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 19:26:02 GMT) Full text and rfc822 format available.Message #56 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Brown <kbrown <at> cornell.edu> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 21:25:17 +0200
> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org > From: Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Sun, 26 Feb 2017 23:39:01 GMT) Full text and rfc822 format available.Message #59 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Sun, 26 Feb 2017 18:38:19 -0500
On 2/26/2017 2:25 PM, Eli Zaretskii wrote:
>> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 08:15:02 GMT) Full text and rfc822 format available.Message #62 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Ken Brown <kbrown <at> cornell.edu> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 08:14:22 +0000
On 26 February 2017 at 23:38, Ken Brown <kbrown <at> cornell.edu> wrote:
> On 2/26/2017 2:25 PM, Eli Zaretskii wrote:
>>>
>>> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org
>>> From: Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 15:37:01 GMT) Full text and rfc822 format available.Message #65 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 17:36:23 +0200
> From: Richard Copley <rcopley <at> gmail.com>
> Date: Mon, 27 Feb 2017 08:14:22 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:05:01 GMT) Full text and rfc822 format available.Message #68 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 19:04:23 +0000
On 27 February 2017 at 15:36, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Richard Copley <rcopley <at> gmail.com>
>> Date: Mon, 27 Feb 2017 08:14:22 +0000
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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 :)
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:18:02 GMT) Full text and rfc822 format available.Message #71 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 21:16:51 +0200
> From: Richard Copley <rcopley <at> gmail.com>
> Date: Mon, 27 Feb 2017 19:04:23 +0000
> Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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).
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:24:02 GMT) Full text and rfc822 format available.Message #74 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 19:23:21 +0000
On 27 February 2017 at 19:16, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Richard Copley <rcopley <at> gmail.com>
>> Date: Mon, 27 Feb 2017 19:04:23 +0000
>> Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:32:02 GMT) Full text and rfc822 format available.Message #77 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 19:30:49 +0000
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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:40:02 GMT) Full text and rfc822 format available.Message #80 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Richard Copley <rcopley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 14:39:17 -0500
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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:47:02 GMT) Full text and rfc822 format available.Message #83 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Ken Brown <kbrown <at> cornell.edu> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 19:46:21 +0000
On 27 February 2017 at 19:39, Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 19:58:02 GMT) Full text and rfc822 format available.Message #86 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Ken Brown <kbrown <at> cornell.edu> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 19:56:24 +0000
On 27 February 2017 at 19:46, Richard Copley <rcopley <at> gmail.com> wrote: > On 27 February 2017 at 19:39, Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 20:20:02 GMT) Full text and rfc822 format available.Message #89 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Richard Copley <rcopley <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 15:19:21 -0500
On 2/27/2017 2:56 PM, Richard Copley wrote: > On 27 February 2017 at 19:46, Richard Copley <rcopley <at> gmail.com> wrote: >> On 27 February 2017 at 19:39, Ken Brown <kbrown <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 20:29:01 GMT) Full text and rfc822 format available.Message #92 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 22:27:41 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Mon, 27 Feb 2017 19:46:21 +0000 > Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 20:53:02 GMT) Full text and rfc822 format available.Message #95 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 20:52:16 +0000
On 27 February 2017 at 20:27, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Mon, 27 Feb 2017 19:46:21 +0000 >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 20:59:01 GMT) Full text and rfc822 format available.Message #98 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 22:58:03 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Mon, 27 Feb 2017 20:52:16 +0000 > Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 21:11:01 GMT) Full text and rfc822 format available.Message #101 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 21:09:52 +0000
On 27 February 2017 at 20:58, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Mon, 27 Feb 2017 20:52:16 +0000 >> Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 22:38:02 GMT) Full text and rfc822 format available.Message #104 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Richard Copley <rcopley <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 17:37:36 -0500
[Message part 1 (text/plain, inline)]
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
[SendMessageTimeout.patch (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Mon, 27 Feb 2017 23:05:02 GMT) Full text and rfc822 format available.Message #107 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Ken Brown <kbrown <at> cornell.edu> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 23:03:26 +0000
On 27 February 2017 at 22:37, Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 03:32:01 GMT) Full text and rfc822 format available.Message #110 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 05:30:50 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Mon, 27 Feb 2017 21:09:52 +0000 > Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 03:36:02 GMT) Full text and rfc822 format available.Message #113 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 05:35:06 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Mon, 27 Feb 2017 23:03:26 +0000 > Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 06:38:01 GMT) Full text and rfc822 format available.Message #116 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 06:37:03 +0000
On 28 February 2017 at 03:30, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Mon, 27 Feb 2017 21:09:52 +0000 >> Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 07:22:01 GMT) Full text and rfc822 format available.Message #119 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 07:21:04 +0000
On 28 February 2017 at 03:35, Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Richard Copley <rcopley <at> gmail.com> >> Date: Mon, 27 Feb 2017 23:03:26 +0000 >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 25875 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 15:37:01 GMT) Full text and rfc822 format available.Message #122 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Richard Copley <rcopley <at> gmail.com> Cc: 25875 <at> debbugs.gnu.org, kbrown <at> cornell.edu Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 17:36:02 +0200
> From: Richard Copley <rcopley <at> gmail.com> > Date: Tue, 28 Feb 2017 07:21:04 +0000 > Cc: Ken Brown <kbrown <at> cornell.edu>, 25875 <at> 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.
Ken Brown <kbrown <at> cornell.edu>:Richard Copley <rcopley <at> gmail.com>:Message #127 received at 25875-done <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Eli Zaretskii <eliz <at> gnu.org>, Richard Copley <rcopley <at> gmail.com> Cc: 25875-done <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 11:40:05 -0500
On 2/28/2017 10:36 AM, Eli Zaretskii wrote: >> From: Richard Copley <rcopley <at> 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
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 16:46:02 GMT) Full text and rfc822 format available.Message #130 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ken Brown <kbrown <at> cornell.edu> Cc: rcopley <at> gmail.com, 25875 <at> debbugs.gnu.org Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 18:44:28 +0200
> Cc: 25875-done <at> debbugs.gnu.org > From: Ken Brown <kbrown <at> 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.
bug-gnu-emacs <at> gnu.org:bug#25875; Package emacs.
(Tue, 28 Feb 2017 19:00:02 GMT) Full text and rfc822 format available.Message #133 received at 25875 <at> debbugs.gnu.org (full text, mbox):
From: Richard Copley <rcopley <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 25875 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu> Subject: Re: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Tue, 28 Feb 2017 18:59:15 +0000
On 28 February 2017 at 16:44, Eli Zaretskii <eliz <at> gnu.org> wrote: >> Cc: 25875-done <at> debbugs.gnu.org >> From: Ken Brown <kbrown <at> 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.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 29 Mar 2017 11:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.