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.