GNU bug report logs - #28472
26.0.50; Deadlock in Fkill_emacs on MS-Windows

Previous Next

Package: emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Sat, 16 Sep 2017 10:32:01 UTC

Severity: normal

Found in version 26.0.50

Done: Stefan Kangas <stefan <at> marxist.se>

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 28472 in the body.
You can then email your comments to 28472 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


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#28472; Package emacs. (Sat, 16 Sep 2017 10:32:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Richard Copley <rcopley <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 16 Sep 2017 10:32:01 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; Deadlock in Fkill_emacs on MS-Windows
Date: Sat, 16 Sep 2017 11:31:21 +0100
[Message part 1 (text/plain, inline)]
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 <at> entry=1, args=args <at> entry=0xbfdb20) at eval.c:2841
#8  0x0000000400178cf1 in Ffuncall (nargs=nargs <at> entry=2,
    args=args <at> entry=0xbfdb18) at eval.c:2766
#9  0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template <at> entry=...,
    nargs=<optimized out>, nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0xbfdf18) at bytecode.c:629
#10 0x0000000400178503 in funcall_lambda (fun=..., fun <at> entry=...,
    nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbfdf18) at eval.c:2967
#11 0x0000000400178c20 in Ffuncall (nargs=nargs <at> entry=1,
    args=args <at> entry=0xbfdf10) at eval.c:2780
#12 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template <at> entry=...,
    nargs=<optimized out>, nargs <at> entry=1, args=<optimized out>,
    args <at> entry=0xbfe690) at bytecode.c:629
#13 0x0000000400178503 in funcall_lambda (fun=..., fun <at> entry=...,
    nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfe690) at eval.c:2967
#14 0x0000000400178c20 in Ffuncall (nargs=nargs <at> entry=2,
    args=args <at> entry=0xbfe688) at eval.c:2780
#15 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template <at> entry=...,
    nargs=<optimized out>, nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0xbff0b8) at bytecode.c:629
#16 0x0000000400178503 in funcall_lambda (fun=..., fun <at> entry=...,
    nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbff0b8) at eval.c:2967
#17 0x0000000400178c20 in Ffuncall (nargs=nargs <at> entry=1,
    args=args <at> entry=0xbff0b0) at eval.c:2780
#18 0x00000004001c6095 in exec_byte_code (bytestr=..., vector=...,
    maxdepth=..., args_template=..., args_template <at> entry=...,
    nargs=<optimized out>, nargs <at> entry=0, args=<optimized out>,
    args <at> entry=0xbff4c0) at bytecode.c:629
#19 0x0000000400178503 in funcall_lambda (fun=..., fun <at> entry=...,
    nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbff4c0) at eval.c:2967
#20 0x000000040017b7dc in apply_lambda (fun=fun <at> entry=..., args=..., count=4,
    count <at> entry=3) at eval.c:2903
#21 0x0000000400177aa3 in eval_sub (form=form <at> 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 <at> entry=0x4000de980 <top_level_2>, handlers=..., handlers <at> entry=...,
    hfun=0xf490, hfun <at> 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 <at> entry=..., func=0x0,
    func <at> entry=0x4000de8e0 <top_level_1>, arg=..., arg <at> 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))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28472; Package emacs. (Sat, 16 Sep 2017 11:16:02 GMT) Full text and rfc822 format available.

Message #8 received at 28472 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28472 <at> debbugs.gnu.org
Subject: Re: bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows
Date: Sat, 16 Sep 2017 14:15:51 +0300
> From: Richard Copley <rcopley <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28472; Package emacs. (Sat, 16 Sep 2017 11:29:01 GMT) Full text and rfc822 format available.

Message #11 received at 28472 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rcopley <at> gmail.com
Cc: 28472 <at> debbugs.gnu.org
Subject: Re: bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows
Date: Sat, 16 Sep 2017 14:28:45 +0300
> Date: Sat, 16 Sep 2017 14:15:51 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 28472 <at> 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.




Reply sent to Stefan Kangas <stefan <at> marxist.se>:
You have taken responsibility. (Mon, 10 Aug 2020 16:48:03 GMT) Full text and rfc822 format available.

Notification sent to Richard Copley <rcopley <at> gmail.com>:
bug acknowledged by developer. (Mon, 10 Aug 2020 16:48:03 GMT) Full text and rfc822 format available.

Message #16 received at 28472-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 28472-done <at> debbugs.gnu.org
Subject: Re: bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows
Date: Mon, 10 Aug 2020 09:47:30 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sat, 16 Sep 2017 14:15:51 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 28472 <at> 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




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 08 Sep 2020 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 221 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.