From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vladimir =?UTF-8?Q?=C5=A0ironja?= Newsgroups: gmane.emacs.bugs Subject: bug#74311: Long startup time on windows (with simple fix) Date: Mon, 11 Nov 2024 12:30:54 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31207"; mail-complaints-to="usenet@ciao.gmane.io" To: 74311@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 11 13:51:37 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 1tATtJ-0007yZ-3B for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Nov 2024 13:51:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tATsu-0004Ur-HT; Mon, 11 Nov 2024 07:51:14 -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 1tATsk-0004TU-NY for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 07:51:02 -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 1tATsk-0004b9-Ev for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 07:51:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:MIME-Version:To:Subject; bh=GlLLlVv3BeNJixMzasCZx/A7S1TGFtNl/Fc/1iSvC78=; b=LwN8o5fQp1/fO9KjhwwpzOkkcCKcp0byyDBME0h2MP/ScNh61eBdTZhFQH37VkwOCrd+n9igaPiMGPx8dcHso8Dl3JFSPNxDhbpDmy0dr9aoHYxEikYu1uOwVxDr7W6Hox6bpUKgEty83TJuLo+XaBwjdLQTqMkXaedG6NZ4YWQ5jgiOedFmTa9wAJBHUbKNVmMhYSH/qd9zzBsfZFLTCKoAX8YtEXFKxqWwKQH/1I6ek8JCokr5f9temSn7BaZkHsS4gPLCnVaUteWfW3vSNvFrpB+rLrSsM+C4YIbPW1yIpY5F7av2GaN/5ByWW7TYJLIooZH5/2EYdW9pZoRpQw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tATsk-0006rZ-8k for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 07:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Vladimir =?UTF-8?Q?=C5=A0ironja?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Nov 2024 12:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74311 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.173132943226337 (code B ref -1); Mon, 11 Nov 2024 12:51:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 11 Nov 2024 12:50:32 +0000 Original-Received: from localhost ([127.0.0.1]:58606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tATsF-0006qi-UV for submit@debbugs.gnu.org; Mon, 11 Nov 2024 07:50:32 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:41018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tASfe-0003Jn-EP for submit@debbugs.gnu.org; Mon, 11 Nov 2024 06:33:27 -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 1tASdR-0000sX-JM for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 06:31:11 -0500 Original-Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tASdP-0003r4-Rl for bug-gnu-emacs@gnu.org; Mon, 11 Nov 2024 06:31:09 -0500 Original-Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-6ea7c9227bfso43708417b3.2 for ; Mon, 11 Nov 2024 03:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731324665; x=1731929465; darn=gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GlLLlVv3BeNJixMzasCZx/A7S1TGFtNl/Fc/1iSvC78=; b=TK5+yWgXHR7Kwz8mjKGJbQvhNbrqzVllBPWWSEAA20zP5VEIsco4Zydb90l4F6nHGJ H4tr9fOOBibMwXVrAs5gq4DziPMRTQ/SSuEk8hNWT2MxLJn1BfT62y2KR5riy6It9Qcx OAxjhsNOAF2llMMLY+QrjPLYPTI0IhPGnBt5gW9+Y0ikfuFDutOIQDPqq0aHBD9znMAg s5FubS3WDFO1U+ztUKCTNTD+BqeqJKvc71CaD+Vy+YYaYWFw9OY8mHsgQK5y7N+sXJiv XidZ03Up72G8e2krdXpZeWrSajkFskFFfXTxzcbwebv3SvqxmURmQ3rNXr13/Yc/8l+C 8ajw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731324665; x=1731929465; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GlLLlVv3BeNJixMzasCZx/A7S1TGFtNl/Fc/1iSvC78=; b=sr0UieLhvLpuvkZhJycBSdFNntaNy1cvtsYmW4T4f0KLJF7Ox2+gyKyMb9Adt5f4xq Qbety/byJHvdQJgak1I7zo1aXgfOFWi/+X9UAvAD05Ie/Cm0QeEG2hhcCO9SJKrU0rlJ RR4jocEMCpKa+XUGlPR99wUXmIEN1eVAB4hYaR0Nr5x15AokA51gpcpPG+3E9Vt9uu7s I0Nr90+/5WOGDPpMGWASwRivvlrCo4PWeRH96S2GKB6cIpmhVsNClFUTT9FFpLEUSKqa t+E7n4ve/7485bI8SeBHr5M7G32rZk3pbPXqUXWobza7Gj92z9NEzVZLB0kWTT4qtnb8 Mc9g== X-Gm-Message-State: AOJu0YwYbxHy+VsrO5SGiVyMZKPoRV5VksHw4EFrv03jFo2hvoogRbIt sRJYcmPSFkPWZL7Gds6m7yx/a+m1Y0XdzAQ13Y0KedC/MigkWOvAlKw7Dwa0FUxQgTnrlXVbFWf 1NPUjgEDImMEyCWxJsHAsQyxBZ9S+rA2EJ7U= X-Google-Smtp-Source: AGHT+IEFr4SzHw5YfO3BhudPjcab4KQ2e2HWpC1pqEJoZBmOLz0bDojnkXV+SwdW8iyH0PsWWOhBGn+/3HlgQiMGpUo= X-Received: by 2002:a05:690c:64c8:b0:6e3:29ae:a3a5 with SMTP id 00721157ae682-6eaddf97896mr113318037b3.34.1731324665027; Mon, 11 Nov 2024 03:31:05 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::1130; envelope-from=vladimir.sironja@gmail.com; helo=mail-yw1-x1130.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 11 Nov 2024 07:50:30 -0500 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:295227 Archived-At: 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=3D0x0, Sid=3D0x4b414a8, Name=3D0xbfe740 "\030D=E2=95=A65\001", cbName=3D0xbfe320, DomainName=3D0x0, cbDomainName=3D0xbfe328, peUse=3D0xbfe314) at w32.c:706 #12 0x00007ff63569d35f in init_user_info () at w32.c:2319 #13 0x00007ff63569f151 in init_environment (argv=3D0xd315b0) at w32.c:3198 #14 0x00007ff6354b93de in main (argc=3D1, argv=3D0xd315b0) at emacs.c:2120 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. However, when lucky, the function is invoked only once and it just works as always. 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. from w32.c: struct lookup_account_sid_cache { BOOL ret; LPTSTR Name; LPSTR DomainName; SID_NAME_USE peUse; }; static BOOL WINAPI lookup_account_sid (LPCTSTR lpSystemName, PSID Sid, LPTSTR Name, LPDWORD cbName, LPTSTR DomainName, LPDWORD cbDomainName, PSID_NAME_USE peUse) { static struct lookup_account_sid_cache cache =3D { 0, NULL, NULL, 0 }; static LookupAccountSid_Proc s_pfn_Lookup_Account_Sid =3D NULL; HMODULE hm_advapi32 =3D NULL; if (is_windows_9x () =3D=3D TRUE) { return FALSE; } if (g_b_init_lookup_account_sid =3D=3D 0) { g_b_init_lookup_account_sid =3D 1; hm_advapi32 =3D LoadLibrary ("Advapi32.dll"); s_pfn_Lookup_Account_Sid =3D (LookupAccountSid_Proc) get_proc_addr (hm_advapi32, LookupAccountSid_Name); } if (s_pfn_Lookup_Account_Sid =3D=3D NULL) { return FALSE; } BOOL ret; if(!cache.ret) { ret =3D s_pfn_Lookup_Account_Sid ( lpSystemName, Sid, Name, cbName, DomainName, cbDomainName, peUse); if(ret) { cache.ret =3D ret; cache.Name =3D Name && *Name ? strdup(Name) : NULL; cache.DomainName =3D DomainName && *DomainName ? strdup(DomainName) := NULL; cache.peUse =3D peUse ? *peUse : 0; } } else { ret =3D cache.ret; if(cache.Name) { strncpy(Name, cache.Name, *cbName); *cbName =3D strlen(cache.Name); } if(cache.DomainName && cbDomainName && *cbDomainName > 0) { if(DomainName) strncpy(DomainName, cache.DomainName, *cbDomainName); *cbDomainName =3D strlen(cache.DomainName); } if(peUse) *peUse =3D cache.peUse; } return ret; } Tried about 30 times since the fix: works like a charm. 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. Cheers to fellow emacsers! And thx for all the good work form the team Bye Vlado