bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows

bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 7921 bytes --]

Very occasionally, Emacs hangs on exit. For example, this happens
sometimes when bootstrapping Emacs (which involves starting emacs.exe
multiple times).

Here is a set of backtraces from attaching gdb to one of the stuck
processes:

Thread 3 (Thread 13168.0x19ec):
#0  0x00007ff80b6f8d61 in ntdll!DbgBreakPoint ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff80b72536b in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff80ac72774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#3  0x00007ff80b6c0d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 13168.0x25a8):
#0  0x00007ff80b6f5424 in ntdll!ZwWaitForSingleObject ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff80b6986ee in ntdll!RtlGetNtProductType ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff80b6720ce in ntdll!LdrShutdownThread ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ff80b6c9bb9 in ntdll!LdrInitializeThunk ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ff80b6c9b1b in ntdll!LdrInitializeThunk ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ff80b6c9ace in ntdll!LdrInitializeThunk ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 13168.0x310):
#0  0x00007ff80b6f5424 in ntdll!ZwWaitForSingleObject ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff80b6986ee in ntdll!RtlGetNtProductType ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff80b69d26f in ntdll!RtlExitUserProcess ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ff80ac7c0da in KERNEL32!FatalExit ()
   from C:\WINDOWS\System32\kernel32.dll
#4  0x00007ff80adca045 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
#5  0x00007ff80adca68d in msvcrt!_initterm_e ()
   from C:\WINDOWS\System32\msvcrt.dll
#6  0x00000004000de21c in Fkill_emacs (arg=...) at emacs.c:2045
#7  0x000000040017a6d6 in funcall_subr (subr=0x400281110 <Skill_emacs>,
    numargs=numargs@entry=1, args=args@entry=0xbfdb20) at eval.c:2841
#8  0x0000000400178cf1 in Ffuncall (nargs=nargs@entry=2,
    args=args@entry=0xbfdb18) at eval.c:2766
#9  0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template@entry=...,
    nargs=<optimized out>, nargs@entry=0, args=<optimized out>,
    args@entry=0xbfdf18) at bytecode.c:629
#10 0x0000000400178503 in funcall_lambda (fun=..., fun@entry=...,
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfdf18) at eval.c:2967
#11 0x0000000400178c20 in Ffuncall (nargs=nargs@entry=1,
    args=args@entry=0xbfdf10) at eval.c:2780
#12 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template@entry=...,
    nargs=<optimized out>, nargs@entry=1, args=<optimized out>,
    args@entry=0xbfe690) at bytecode.c:629
#13 0x0000000400178503 in funcall_lambda (fun=..., fun@entry=...,
    nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfe690) at eval.c:2967
#14 0x0000000400178c20 in Ffuncall (nargs=nargs@entry=2,
    args=args@entry=0xbfe688) at eval.c:2780
#15 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template@entry=...,
    nargs=<optimized out>, nargs@entry=0, args=<optimized out>,
    args@entry=0xbff0b8) at bytecode.c:629
#16 0x0000000400178503 in funcall_lambda (fun=..., fun@entry=...,
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbff0b8) at eval.c:2967
#17 0x0000000400178c20 in Ffuncall (nargs=nargs@entry=1,
    args=args@entry=0xbff0b0) at eval.c:2780
#18 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template@entry=...,
    nargs=<optimized out>, nargs@entry=0, args=<optimized out>,
    args@entry=0xbff4c0) at bytecode.c:629
#19 0x0000000400178503 in funcall_lambda (fun=..., fun@entry=...,
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbff4c0) at eval.c:2967
#20 0x000000040017b7dc in apply_lambda (fun=fun@entry=..., args=..., count=4,
    count@entry=3) at eval.c:2903
#21 0x0000000400177aa3 in eval_sub (form=form@entry=...) at eval.c:2306
#22 0x000000040017bc9f in Feval (form=..., lexical=...) at eval.c:2051
#23 0x00000004001768d6 in internal_condition_case (
    bfun=0x4005c0000 <tzbuf_format+752>,
    bfun@entry=0x4000de980 <top_level_2>, handlers=..., handlers@entry=...,
    hfun=0xf490, hfun@entry=0x4000e1600 <cmd_error>) at eval.c:1332
#24 0x00000004000de93d in top_level_1 (ignore=...) at keyboard.c:1131
#25 0x000000040017676a in internal_catch (tag=..., tag@entry=..., func=0x0,
    func@entry=0x4000de8e0 <top_level_1>, arg=..., arg@entry=...)
    at eval.c:1097
#26 0x00000004000de845 in command_loop () at keyboard.c:1092
#27 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



In GNU Emacs 26.0.50 (build 1, x86_64-w64-mingw32)
 of 2017-09-14 built on MACHINE
Repository revision: 0d5f0a8d56bb7e15607c77a7d5d6e36776eff94d
Windowing system distributor 'Microsoft Corp.', version 10.0.15063
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
mwheel-scroll: Beginning of buffer

Configured using:
 'configure --with-modules --without-pop 'CFLAGS=-O3 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES LCMS2

Important settings:
  value of $EMACSLOADPATH: c:\emacs-lisp;
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 97046 10925)
 (symbols 56 20144 1)
 (miscs 48 39 87)
 (strings 32 29581 1047)
 (string-bytes 1 746755)
 (vectors 16 13998)
 (vector-slots 8 482061 7969)
 (floats 8 50 79)
 (intervals 56 232 0)
 (buffers 992 11))

[-- Attachment #2: Type: text/html, Size: 13276 bytes --]

bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 16 Sep 2017 11:31:21 +0100
> 
> Very occasionally, Emacs hangs on exit. For example, this happens
> sometimes when bootstrapping Emacs (which involves starting emacs.exe
> multiple times).
> 
> Here is a set of backtraces from attaching gdb to one of the stuck
> processes:

Thanks.  I see nothing in this backtrace that could tell what to do to
avoid the hang.  All the threads are stuck in system calls, two of
then in WaitForSingleObject.  So it sounds like some race condition,
but I have no idea what that could be.  FWIW, it never happened to me
during a bootstrap.

It could be bug#14333, which we never solved.  But the backtraces
there were more informative.

bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows

[Eli Zaretskii]

> Date: Sat, 16 Sep 2017 14:15:51 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 28472@debbugs.gnu.org
> 
> Thanks.  I see nothing in this backtrace that could tell what to do to
> avoid the hang.  All the threads are stuck in system calls, two of
> then in WaitForSingleObject.  So it sounds like some race condition,
> but I have no idea what that could be.  FWIW, it never happened to me
> during a bootstrap.
> 
> It could be bug#14333, which we never solved.  But the backtraces
> there were more informative.

One possible way to gain more info is to add printf's in several
places in term_timers and in term_ntproc, and see what this tells us
about where Emacs gets stuck.  But make sure bootstrap commands don't
redirect stdout/stderr to some place, or you may not see the output.

bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 16 Sep 2017 14:15:51 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 28472@debbugs.gnu.org
>>
>> Thanks.  I see nothing in this backtrace that could tell what to do to
>> avoid the hang.  All the threads are stuck in system calls, two of
>> then in WaitForSingleObject.  So it sounds like some race condition,
>> but I have no idea what that could be.  FWIW, it never happened to me
>> during a bootstrap.
>>
>> It could be bug#14333, which we never solved.  But the backtraces
>> there were more informative.
>
> One possible way to gain more info is to add printf's in several
> places in term_timers and in term_ntproc, and see what this tells us
> about where Emacs gets stuck.  But make sure bootstrap commands don't
> redirect stdout/stderr to some place, or you may not see the output.

No more information was given within 2 years, 46 weeks. Since the
backtrace was not enough to make any progress, I'm closing this bug now.

If this is still an issue, please reply to this email (use "Reply to
all" in your email client) and we can reopen the bug report.

Best regards,
Stefan Kangas