From: Eli Zaretskii <eliz@gnu.org>
To: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
Cc: 12587@debbugs.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 16:53:01 +0200 [thread overview]
Message-ID: <837gqt5cmq.fsf@gnu.org> (raw)
In-Reply-To: <507AB825.6070002@uni-muenster.de>
> Date: Sun, 14 Oct 2012 15:03:33 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
>
> Just so we're on the same page this is roughly the timeline:
> (start emacs)----------------(GUI
> appears)----------------------------------------------------(welcome screen)
> 0s ------------------------------- ~2 min
> --------------------------------------------------------------- ~7 min
Yes, I understand that.
> >> 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?
No, it isn't necessarily so. Emacs does a series of initializations
during these phases, and looks for quite a long list of files, so you
might as well see an entirely different backtrace. I'd like to make
sure that LookupAccountSidW, called from 'stat', is the only function
that slows down the startup.
> > 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?
No, that's fine. I think the issue with CreateThread is a red herring
anyway, sorry. The only additional information I'd like to see is the
backtrace during the time between the instance the GUI shows up and
the welcome screen.
Thanks.
next prev parent reply other threads:[~2012-10-14 14:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-06 10:05 bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain Mohammed Imaduddin Humayun
2012-10-06 17:40 ` Eli Zaretskii
2012-10-07 10:12 ` Mohammed Imaduddin Humayun
2012-10-07 11:02 ` Eli Zaretskii
2012-10-08 8:49 ` Mohammed Imaduddin Humayun
2012-10-08 9:15 ` Eli Zaretskii
2012-10-08 14:34 ` Mohammed Imaduddin Humayun
2012-10-08 15:47 ` Eli Zaretskii
2012-10-12 15:27 ` Eli Zaretskii
2012-10-14 13:03 ` Mohammed Imaduddin Humayun
2012-10-14 14:53 ` Eli Zaretskii [this message]
2012-10-17 8:47 ` Mohammed Imaduddin Humayun
2012-10-17 16:14 ` Eli Zaretskii
2014-02-05 2:11 ` Lars Ingebrigtsen
2014-02-05 3:50 ` Eli Zaretskii
2014-02-05 8:54 ` Mohammed Imaduddin Humayun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837gqt5cmq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12587@debbugs.gnu.org \
--cc=m_huma01@uni-muenster.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.