GNU bug report logs - #12587
24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

Previous Next

Full log

View this message in rfc822 format

From: Mohammed Imaduddin Humayun <m_huma01 <at> uni-muenster.de>
To: 12587 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when	netlogon	services is running in a domain
Date: Sun, 14 Oct 2012 15:03:33 +0200

On 10/12/2012 5:27 PM, Eli Zaretskii wrote:
> I committed a change in trunk revision 110520 which should make this
> part faster, as these functions now avoid calling 'stat' as much as
> possible.  When the binaries of the next development snapshot appear
> on http://alpha.gnu.org/gnu/emacs/windows/, or if you can build Emacs
> yourself, please try that and see if things are better now when the
> Netlogon service is running.
Thanks. I will try this once the next snapshot binaries are released or 
earlier if I manage to build it myself.
>> I see that I misinterpreted your original report about the startup
>> time line.  I now understand that after the welcome screen Emacs is
>> responsive, and the slowdown is before the welcome screen.
Just so we're on the same page this is roughly the timeline:
(start emacs)----------------(GUI 
appears)----------------------------------------------------(welcome screen)
   0s ------------------------------- ~2 min 
--------------------------------------------------------------- ~7 min
>> So please repeat what you did, but do it once before the GUI shows up,
>> and then again between the time the GUI shows up and the time Emacs
>> shows its welcome screen.  (If you know to which of these two time
>> instances belongs the first backtrace you show above, you need only to
>> produce the backtrace for the other time instance.)
I'm not clear on this. Wouldn't the backtrace be the same if I just 
produce it for the latter time instance (welcome screen) given that this 
happens only after the GUI shows up?

> I'd still like to see this information, to make sure there isn't any
> other place that slows down the startup.
Sorry I couldn't find time to do this sooner, but the following steps 
didn't give the backtrace as expected  ... :

cd \path\to\emacs.exe
gdb ./emacs.exe
(gdb) break CreateThread
(Answer 'y' when GDB asks whether to make this breakpoint pending on future shared
library load)
(gdb) commands
backtrace
continue
end
(gdb) run -Q


... and below is the log, but no backtrace was shown:
------------------------------------------------------
Function "CreateThread" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Breakpoint 1 (CreateThread) pending.
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
Starting program: C:\emacs-24.2.50\bin\emacs.exe
[New Thread 9940.0x2db0]
[New Thread 9940.0x2bbc]
[New Thread 9940.0x2c0c]
[New Thread 9940.0x2ed0]
[New Thread 9940.0x2840]
[New Thread 9940.0xe8c]
[New Thread 9940.0x7e8]
[New Thread 9940.0xe3c]
[New Thread 9940.0x1284]
[New Thread 9940.0x11d4]
[Inferior 1 (process 9940) exited normally]
-------------------------------------------------------------

What do I need to rectify here?

Previous Next

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