--- Begin Message ---
|
Subject: |
29.1; emacs freeze with memory swap |
|
Date: |
Mon, 19 Feb 2024 14:56:10 +0900 |
My PC has 8GB memory and HDD, no SSD.
Emacs freezes with the procedure below.
(0) Close all applications.
(1) Start task manager.
Confirm disk usage is low and memory usage is about 2GB or less.
(2) Start emacs -Q
(3) Evaluate the form below
(progn (make-string (* 8000 1000 1000) 0)
(kill-emacs))
(4) Memory usage increases and then decreases in ten seconds.
(5) Disk usage keep 100% active for a few minutes.
(6) Application window of emacs keep alive and emacs process name is
displayed in the process tab of task manager.
(At least 10 hours, I waited.)
In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4046)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: JPN
locale-coding-system: cp932
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils term/bobcat japan-util rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode 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 lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process
native-compile emacs)
Memory information:
((conses 16 51566 9231)
(symbols 48 5198 0)
(strings 32 15196 1637)
(string-bytes 1 409249)
(vectors 16 10772)
(vector-slots 8 335055 18016)
(floats 8 35 38)
(intervals 56 228 9)
(buffers 984 10))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#69263: 29.1; emacs freeze with memory swap |
|
Date: |
Sun, 9 Jun 2024 16:56:04 -0400 |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: awrhygty@outlook.com
>> Cc: 69263@debbugs.gnu.org
>> Date: Wed, 21 Feb 2024 00:33:58 +0900
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > This backtrace is not from an interesting thread. You need to say
>> > "thread 1" before "bt full", to switch to the Emacs's main
>> > (a.k.a. "Lisp") thread.
>> >
>> > Alternatively, say "thread apply all bt full", which will produce the
>> > backtrace of all the threads in the program.
>>
>> I tried "thread apply all bt full".
>> Here is a new log.
>
> Thanks.
>
>> Thread 1 (Thread 1384.0x1fdc):
>> #0 0x00007ffa7370d064 in ntdll!ZwWaitForSingleObject () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> No symbol table info available.
>> #1 0x00007ffa736ceb32 in ntdll!RtlUnlockHeap () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> No symbol table info available.
>> #2 0x00007ffa736cda08 in ntdll!RtlExitUserProcess () from
>> C:\WINDOWS\SYSTEM32\ntdll.dll
>> No symbol table info available.
>> #3 0x00007ffa7223e3bb in KERNEL32!FatalExit () from
>> C:\WINDOWS\System32\kernel32.dll
>> No symbol table info available.
>> #4 0x00007ffa71daa155 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
>> No symbol table info available.
>> #5 0x00007ffa71daa7c5 in msvcrt!_initterm_e () from
>> C:\WINDOWS\System32\msvcrt.dll
>> No symbol table info available.
>> #6 0x00007ff68b906996 in Fkill_emacs ()
>
> This seems to indicate that Emacs already called 'exit' inside
> kill-emacs, and the process is now stuck inside the Microsoft exit
> code, waiting (in WaitForSingleObject, it seems) for something to
> happen. The fact that RtlUnlockHeap is in the call-stack seems to
> indicate that releasing memory might be somehow related to this.
>
> OTOH, this page:
>
>
> https://stackoverflow.com/questions/52649476/why-would-a-process-hang-within-rtlexituserprocess-ldrpdrainworkqueue
>
> discusses a similar issue, and points to this page:
>
>
> https://blogs.blackberry.com/en/2017/10/windows-10-parallel-loading-breakdown
>
> which seems to indicate that this is somehow related to the "parallel
> DLL loading" feature of Windows, and indeed, one of the threads within
> the Emacs process shows calls to LdrInitializeThunk and
> LdrShutdownThread in its call-stack. It might be interesting to look
> at the Emacs process with Process Explorer and try to figure out which
> thread is running (as opposed to threads that are idle waiting for
> something); if it's the thread which calls those Ldr* functions, it
> will be one more evidence that this parallel loading feature is
> related somehow.
>
> That's all I can say based on this information, sorry.
More information was requested, but none was given within 15 weeks, so
I'm closing this bug. 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.
--- End Message ---