bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when


From: Mohammed Imaduddin Humayun
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
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

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?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]