bug#69263: 29.1; emacs freeze with memory swap

bug#69263: 29.1; emacs freeze with memory swap

[awrhygty]

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

bug#69263: 29.1; emacs freeze with memory swap

[Eli Zaretskii]

tags 69263 moreinfo
thanks

> From: awrhygty@outlook.com
> 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.)

I don't have a 8GB 64-bit Windows system to try this, and the results
are likely to be dependent on the intimate details of the Virtual
Memory setup on that system.

So if you want to help us understand what happens in the strange case
where a Lisp program creates a 8GB Lisp string, and clear it all, on a
8GB MS-Windows system, please attach GDB to Emacs after running the
above recipe, and produce a backtrace that can be used to try to
figure out what happens.  (I hope that your Emacs binary is not
stripped of debugging symbols, because if it's stripped, GDB will not
tell anything useful.)

Thanks.

bug#69263: 29.1; emacs freeze with memory swap

[awrhygty]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 69263 moreinfo
> thanks
>
>> From: awrhygty@outlook.com
>> 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.)
>
> I don't have a 8GB 64-bit Windows system to try this, and the results
> are likely to be dependent on the intimate details of the Virtual
> Memory setup on that system.
>
> So if you want to help us understand what happens in the strange case
> where a Lisp program creates a 8GB Lisp string, and clear it all, on a
> 8GB MS-Windows system, please attach GDB to Emacs after running the
> above recipe, and produce a backtrace that can be used to try to
> figure out what happens.  (I hope that your Emacs binary is not
> stripped of debugging symbols, because if it's stripped, GDB will not
> tell anything useful.)
>
> Thanks.

I installed MSYS2 and GDB for this.
At first, I tried to attach with emacs PID.
GDB says "Can't attach to process 1099".
So I tried with WINPID.
I am not sure it is a correct parameter.

Here is a log within MSYS2 shell:
$ ps
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     1051       1    1051       3940  ?         197609 20:56:49 /usr/bin/mintty
     1205    1052    1205       9776  pty0      197609 22:26:16 /usr/bin/ps
     1052    1051    1052      11328  pty0      197609 20:56:49 /usr/bin/bash
     1099    1052    1099       1384  pty0      197609 21:10:57 /c/Emacs/emacs-29.1/bin/emacs
$ /mingw64/bin/gdb
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 1384
Attaching to process 1384
[New Thread 1384.0xbbc]
[New Thread 1384.0xbe0]
[New Thread 1384.0x2bc0]
[New Thread 1384.0x2cc4]
[New Thread 1384.0x14a4]
Reading symbols from C:\Emacs\emacs-29.1\bin\emacs.exe...
(gdb) bt full
#0  0x00007ffa73710b11 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffa7373ca0e in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) detach
Detaching from program: C:\Emacs\emacs-29.1\bin\emacs.exe, process 1384
[Inferior 1 (process 1384) detached]
(gdb) exit

bug#69263: 29.1; emacs freeze with memory swap

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Cc: 69263@debbugs.gnu.org
> Date: Tue, 20 Feb 2024 22:33:35 +0900
> 
> > So if you want to help us understand what happens in the strange case
> > where a Lisp program creates a 8GB Lisp string, and clear it all, on a
> > 8GB MS-Windows system, please attach GDB to Emacs after running the
> > above recipe, and produce a backtrace that can be used to try to
> > figure out what happens.  (I hope that your Emacs binary is not
> > stripped of debugging symbols, because if it's stripped, GDB will not
> > tell anything useful.)
> >
> > Thanks.
> 
> I installed MSYS2 and GDB for this.
> At first, I tried to attach with emacs PID.
> GDB says "Can't attach to process 1099".
> So I tried with WINPID.
> I am not sure it is a correct parameter.
> 
> Here is a log within MSYS2 shell:
> $ ps
>       PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
>      1051       1    1051       3940  ?         197609 20:56:49 /usr/bin/mintty
>      1205    1052    1205       9776  pty0      197609 22:26:16 /usr/bin/ps
>      1052    1051    1052      11328  pty0      197609 20:56:49 /usr/bin/bash
>      1099    1052    1099       1384  pty0      197609 21:10:57 /c/Emacs/emacs-29.1/bin/emacs
> $ /mingw64/bin/gdb
> GNU gdb (GDB) 13.2
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) attach 1384
> Attaching to process 1384
> [New Thread 1384.0xbbc]
> [New Thread 1384.0xbe0]
> [New Thread 1384.0x2bc0]
> [New Thread 1384.0x2cc4]
> [New Thread 1384.0x14a4]
> Reading symbols from C:\Emacs\emacs-29.1\bin\emacs.exe...
> (gdb) bt full
> #0  0x00007ffa73710b11 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #1  0x00007ffa7373ca0e in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #2  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
> No symbol table info available.
> #3  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #4  0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb) detach
> Detaching from program: C:\Emacs\emacs-29.1\bin\emacs.exe, process 1384
> [Inferior 1 (process 1384) detached]
> (gdb) exit

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.

Thanks.

bug#69263: 29.1; emacs freeze with memory swap

[awrhygty]

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.

$ /mingw64/bin/gdb
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 1384
Attaching to process 1384
[New Thread 1384.0xbbc]
[New Thread 1384.0xbe0]
[New Thread 1384.0x2bc0]
[New Thread 1384.0x2cc4]
[New Thread 1384.0xef8]
Reading symbols from C:\Emacs\emacs-29.1\bin\emacs.exe...
(gdb) thread apply all bt full

Thread 6 (Thread 1384.0xef8):
#0  0x00007ffa73710b11 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffa7373ca0e in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 1384.0x2cc4):
#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  0x00007ffa736877c3 in ntdll!LdrShutdownThread () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#3  0x00007ffa736e5064 in ntdll!LdrInitializeThunk () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x00007ffa736e4c43 in ntdll!LdrInitializeThunk () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#5  0x00007ffa736e4bee in ntdll!LdrInitializeThunk () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
--Type <RET> for more, q to quit, c to continue without paging--c
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 1384.0x2bc0):
#0  0x00007ffa73710a74 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffa736c2e27 in ntdll!TpReleaseCleanupGroupMembers () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 1384.0xbe0):
#0  0x00007ffa73710a74 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffa736c2e27 in ntdll!TpReleaseCleanupGroupMembers () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 1384.0xbbc):
#0  0x00007ffa70ec1104 in win32u!NtUserGetMessage () from C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#1  0x00007ffa7337226e in USER32!GetMessageW () from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#2  0x00007ff68ba35ce9 in w32_msg_pump ()
No symbol table info available.
#3  0x00007ff68ba3641b in w32_msg_worker ()
No symbol table info available.
#4  0x00007ffa72237344 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#5  0x00007ffa736c26b1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

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 ()
No symbol table info available.
#7  0x00007ff68b9997a6 in eval_sub ()
No symbol table info available.
#8  0x00007ff68b9999dd in Fprogn ()
No symbol table info available.
#9  0x00007ff68b99965d in eval_sub ()
No symbol table info available.
#10 0x00007ff68b9999dd in Fprogn ()
No symbol table info available.
#11 0x00007ff68b99965d in eval_sub ()
No symbol table info available.
#12 0x00007ff68b99bf3b in Feval ()
No symbol table info available.
#13 0x00007ffa5a86f609 in F656c6973702d2d6576616c2d6c6173742d73657870_elisp__eval_last_sexp_0 () fro
m c:\Emacs\emacs-29.1\lib\emacs\29.1\native-lisp\29.1-ece58e2c\preloaded\elisp-mode-90dbfe40-1c21c6d
f.eln
No symbol table info available.
#14 0x00007ff68b995648 in Ffuncall ()
No symbol table info available.
#15 0x00007ffa5a86fad5 in F6576616c2d6c6173742d73657870_eval_last_sexp_0 () from c:\Emacs\emacs-29.1
\lib\emacs\29.1\native-lisp\29.1-ece58e2c\preloaded\elisp-mode-90dbfe40-1c21c6df.eln
No symbol table info available.
#16 0x00007ff68b995648 in Ffuncall ()
No symbol table info available.
#17 0x00007ffa5a86e395 in F6576616c2d7072696e742d6c6173742d73657870_eval_print_last_sexp_0 () from c
:\Emacs\emacs-29.1\lib\emacs\29.1\native-lisp\29.1-ece58e2c\preloaded\elisp-mode-90dbfe40-1c21c6df.e
ln
No symbol table info available.
#18 0x00007ff68b995648 in Ffuncall ()
No symbol table info available.
#19 0x00007ff68b9912b7 in Ffuncall_interactively ()
No symbol table info available.
#20 0x00007ff68b995648 in Ffuncall ()
No symbol table info available.
#21 0x00007ff68b992647 in Fcall_interactively ()
No symbol table info available.
#22 0x00007ffa61ceefdf in F636f6d6d616e642d65786563757465_command_execute_0 () from c:\Emacs\emacs-2
9.1\lib\emacs\29.1\native-lisp\29.1-ece58e2c\preloaded\simple-fab5b0cf-a050dc2b.eln
No symbol table info available.
#23 0x00007ff68b995648 in Ffuncall ()
No symbol table info available.
#24 0x00007ff68b91bd82 in command_loop_1 ()
No symbol table info available.
#25 0x00007ff68b993c3d in internal_condition_case ()
No symbol table info available.
#26 0x00007ff68b90735e in command_loop_2 ()
No symbol table info available.
#27 0x00007ff68b993bab in internal_catch ()
No symbol table info available.
#28 0x00007ff68b9072ec in command_loop ()
No symbol table info available.
#29 0x00007ff68b90f93d in recursive_edit_1 ()
No symbol table info available.
#30 0x00007ff68b90fd00 in Frecursive_edit ()
No symbol table info available.
#31 0x00007ff68baacf0b in main ()
No symbol table info available.
(gdb) detach
Detaching from program: C:\Emacs\emacs-29.1\bin\emacs.exe, process 1384
[Inferior 1 (process 1384) detached]
(gdb) exit

bug#69263: 29.1; emacs freeze with memory swap

[Eli Zaretskii]

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

bug#69263: 29.1; emacs freeze with memory swap

[Stefan Kangas]

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.