emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: GNU bug Tracking System
Subject: bug#28472: closed (26.0.50; Deadlock in Fkill_emacs on MS-Windows)
Date: Mon, 10 Aug 2020 16:48:03 +0000

Your message dated Mon, 10 Aug 2020 09:47:30 -0700
with message-id 
<CADwFkmkS5vugJ=QjH4-7CLcx9Opaq+gSKUDh+_eRcZyjAc9vQg@mail.gmail.com>
and subject line Re: bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows
has caused the debbugs.gnu.org bug report #28472,
regarding 26.0.50; Deadlock in Fkill_emacs on MS-Windows
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
28472: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28472
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 26.0.50; Deadlock in Fkill_emacs on MS-Windows 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:

 

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))


--- End Message ---
--- Begin Message --- Subject: Re: bug#28472: 26.0.50; Deadlock in Fkill_emacs on MS-Windows Date: Mon, 10 Aug 2020 09:47:30 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]