bug#69263: 29.1; emacs freeze with memory swap

[Eli Zaretskii <eliz@gnu.org>]

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