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#74311: Long startup time on windows (with simple fix) Date: Mon, 11 Nov 2024 15:13:51 +0200 Message-ID: <86v7wtkj5c.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8558"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74311@debbugs.gnu.org To: Vladimir =?UTF-8?Q?=C5=A0ironja?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 11 14:15:35 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 1tAUGV-00022Y-AW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Nov 2024 14:15:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAUGB-0001jD-35; Mon, 11 Nov 2024 08:15:15 -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 1tAUG1-0001fB-RI for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 08:15:06 -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 1tAUFy-0007zH-3t for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 08:15:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=Or72rTmo1bd4JanwExDzvJ/cQ6rd+aPK+Ll8VisFcu4=; b=KTy5nhKw6Mrnr1vslnOav15rQbN5OmGceMR5/yWR2Q2UKmhFpc1UPFMm6tJ3OAHLLaRIbVVto2ygaZe9yNokyEPYypAdO3UxA8EFj458D75og3IzNDSfOELmeqkKDvEjjyjc9EKm3ION6A2wpfdW06dxdRfXgo7WpTGQLZrwVvmYn8+UnWJ8oku6HKD/w37iH+iYyLco8b42VnpNuUYT/Dsu5JAOQWDYFLeV0qo7edI4Wmlek3XiZ2HbVUexpFq0lcSakADXyjnw63isZ36Zs2LAzMytJS2Eu1VrsZIpOzYHQ9YcAcoaIDW8RWIK3KgsM6y7cPw+4CPyBwZgxFUxpw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tAUFx-0007pe-NB for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 08:15: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: Mon, 11 Nov 2024 13:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74311 X-GNU-PR-Package: emacs Original-Received: via spool by 74311-submit@debbugs.gnu.org id=B74311.173133085330024 (code B ref 74311); Mon, 11 Nov 2024 13:15:01 +0000 Original-Received: (at 74311) by debbugs.gnu.org; 11 Nov 2024 13:14:13 +0000 Original-Received: from localhost ([127.0.0.1]:58631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAUFA-0007oB-Fk for submit@debbugs.gnu.org; Mon, 11 Nov 2024 08:14:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAUF8-0007nz-Pz for 74311@debbugs.gnu.org; Mon, 11 Nov 2024 08:14:11 -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 1tAUEz-0007vI-Ag; Mon, 11 Nov 2024 08:14:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Or72rTmo1bd4JanwExDzvJ/cQ6rd+aPK+Ll8VisFcu4=; b=c7N4xq0kuBJu+ijZR5NR e1M668313YVGkJarAQUpc1eRTQJ7Zbls+DqQLbLgkSH2PfnaDmUHD2jDFK26bHo/qg6oEqqE7tDaO LI+Mt43G7DDvsV0JUlZTPHWc8DBWHgtiYj3frvi3/0MaijYYalI/rISC7eTVJ/HEQBZc8SdxyY8d5 eKySeikUnaPLLS2laWtBZMT9fk3HHeeTdSwmQYQkLlma33TeMbzvw1zC3trshcLlGN0IUdH4jaT7V 90XEca98axQ0XF6dlP0meSonmwif+IPOpdY1ns2pFLdMOEt3typpToxb6gz0zDPT/Cg5937eUu3oG U88OUmfNW1Neew==; In-Reply-To: (message from Vladimir =?UTF-8?Q?=C5=A0ironja?= on Mon, 11 Nov 2024 12:30:54 +0100) 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:295228 Archived-At: > From: Vladimir Šironja > Date: Mon, 11 Nov 2024 12:30:54 +0100 > > Hello, > I have (*had!) a very annoying occurrence of long startup times on > windows 10 & 11. > Ended up with emacs 29.4 but tried several 28 and 26 versions with no > difference. > It takes sometimes around 30 secs for emacs to come up. > But not always, let's say a third of strarts were normal within a second. > Tried excluding relevant directories from virus check; no difference. > Also tried starting without init files (-Q); no difference. > So compiled with debug symbols gcc version 14.2.0 on msys2. > (Had to set manually add "#define HAVE_SYS_WAIT_H 1" into src/config.h > - but that's another issue, already handled several times in this > group.) > > In gdb-debugger caught the hanging operation: > > Thread 1 (Thread 19568.0x24c0): > #0 0x00007ff9e2331244 in ntdll!ZwAlpcSendWaitReceivePort () from > C:\WINDOWS\SYSTEM32\ntdll.dll > #1 0x00007ff9e0a4b032 in RpcBindingFromStringBindingW () from > C:\WINDOWS\System32\rpcrt4.dll > #2 0x00007ff9e0a47efb in RpcBindingFromStringBindingW () from > C:\WINDOWS\System32\rpcrt4.dll > #3 0x00007ff9e0a66c19 in RPCRT4!I_RpcSendReceive () from > C:\WINDOWS\System32\rpcrt4.dll > #4 0x00007ff9e0a66b5f in RPCRT4!NdrSendReceive () from > C:\WINDOWS\System32\rpcrt4.dll > #5 0x00007ff9e0af07da in RPCRT4!NdrClientCall3 () from > C:\WINDOWS\System32\rpcrt4.dll > #6 0x00007ff9e0aef69b in RPCRT4!NdrClientCall3 () from > C:\WINDOWS\System32\rpcrt4.dll > #7 0x00007ff9e11c6046 in SECHOST!LookupAccountSidLocalW () from > C:\WINDOWS\System32\sechost.dll > #8 0x00007ff9e11c5d4f in SECHOST!LookupAccountSidLocalW () from > C:\WINDOWS\System32\sechost.dll > #9 0x00007ff9e11dead3 in SECHOST!LookupAccountSidLocalA () from > C:\WINDOWS\System32\sechost.dll > #10 0x00007ff9e0d9bce0 in LookupAccountSidA () from > C:\WINDOWS\System32\advapi32.dll > #11 0x00007ff63569a990 in lookup_account_sid (lpSystemName=0x0, > Sid=0x4b414a8, Name=0xbfe740 "\030D╦5\001", cbName=0xbfe320, > DomainName=0x0, cbDomainName=0xbfe328, peUse=0xbfe314) at w32.c:706 > #12 0x00007ff63569d35f in init_user_info () at w32.c:2319 > #13 0x00007ff63569f151 in init_environment (argv=0xd315b0) at w32.c:3198 > #14 0x00007ff6354b93de in main (argc=1, argv=0xd315b0) at emacs.c:2120 So this is a completely different issue, and should have been submitted as a separate bug report. > Ok, so noticed that it if s_pfn_Lookup_Account_Sid (LookupAccountSid) > invoked for the *second* time, it blocks for around half a minute > causing the delay. The questions is: why does it happen on your system. It doesn't happen here on my Windows 11 system, and never happened on my previous and other Windows systems where I use Emacs with this code. Are you working on a system under a domain controller, where Net Logon service is enabled? We have a known problem described in etc/PROBLEMS, with a possible solution; search for "Net Logon". If that solution helps, then maybe your Domain Controller is set up sub-optimally, and need to be looked into. > I didn't analyse the cause for multiple invocations, but added a > simple naive workaround to test the theory - which simply caches the > results of LookupAccountSid. Caching the results of LookupAccountSid is problematic: the results might change behind Emacs's back, and we have no good way of knowing when that happens (to invalidate the cache). > Please change the code - to invoke the offending winapi function only > once, since it obviously punishes the second caller. Or perhaps a > caching mechanism as above. Can you show the backtraces for the two calls to LookupAccountSid? The two calls inside lookup_account_sid are not identical: the first gets information about the user, the second about its group. So if you are talking about using just one of these two, then the results will not be correct for the user's group. But if you see two calls to LookupAccountSid with the same arguments, then please show the backtraces from these duplicate calls. P.S. If you want to keep discussing this bug further, please submit a separate new bug report using "M-x report-emacs-bug".