GNU bug report logs - #74311
Long startup time on windows (with simple fix)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vladimir Šironja <vladimir.sironja <at> gmail.com>
Cc: 74311 <at> debbugs.gnu.org
Subject: bug#74311: Long startup time on windows (with simple fix)
Date: Mon, 11 Nov 2024 15:13:51 +0200

> From: Vladimir Šironja <vladimir.sironja <at> gmail.com>
> 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".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.