From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69263: 29.1; emacs freeze with memory swap Date: Tue, 20 Feb 2024 19:08:18 +0200 Message-ID: <86h6i3njwd.fsf@gnu.org> References: <86wmr0pqw9.fsf@gnu.org> <86msrvnqq4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11793"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69263@debbugs.gnu.org To: awrhygty@outlook.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 20 18:09:06 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rcTc9-0002n4-SH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Feb 2024 18:09:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcTbl-0005tr-KF; Tue, 20 Feb 2024 12:08:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcTbk-0005ro-P8 for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 12:08:40 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rcTbk-0007Xj-G6 for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 12:08:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rcTc5-0006ub-VM for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 12:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Feb 2024 17:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69263 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 69263-submit@debbugs.gnu.org id=B69263.170844893326555 (code B ref 69263); Tue, 20 Feb 2024 17:09:01 +0000 Original-Received: (at 69263) by debbugs.gnu.org; 20 Feb 2024 17:08:53 +0000 Original-Received: from localhost ([127.0.0.1]:46442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rcTbx-0006uE-9a for submit@debbugs.gnu.org; Tue, 20 Feb 2024 12:08:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rcTbt-0006tz-L1 for 69263@debbugs.gnu.org; Tue, 20 Feb 2024 12:08:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcTbR-0007Vm-Ni; Tue, 20 Feb 2024 12:08:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s6btfe+X2FbbSATR/W8hCXC7NYim/cR5+fTCChx97ps=; b=dizVa2h2bCOu o5IDJ9n/gTRsbh3efCnGeFYPHAsn+CXRKX/0/P4jRx4KdUqwzaSd31i6b/lMezss2uBfLBWYIQM+Q KIM6e+hCZtBUfmTlwXgZdjpm/1JJdg6TdkN/S2U6nAGhBTM05ys3XJ/ehuGfOvycv3t5gPo9wgkyg 8OS+XB78h+9gRAyzfDk+iRwSUxFQ8i6UMpuLiIo9Md+perWtxfSmY2e6haXPiXRYRtjyXm3RFZCj9 qBqEWzUj1Tx7u9eUuexXUPeP21f7pTYnrK5swXWK52QCXP+IhkDEX8whbNL/hMzsSbnXJl6VAaB/v Twon9Co7DQiFBFkDG8/TCA==; In-Reply-To: (awrhygty@outlook.com) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280342 Archived-At: > From: awrhygty@outlook.com > Cc: 69263@debbugs.gnu.org > Date: Wed, 21 Feb 2024 00:33:58 +0900 > > Eli Zaretskii 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.