Re: commands spends time in cygheap_user

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Aug 10 18:01, Corinna Vinschen wrote:
> On Aug 10 05:00, mku wrote:
> > Oh, sorry. I did a fresh 2.2 install to avoid side effects from my previous
> > updated one and forgot to modify the nsswitch.conf. After correcting it, the
> > result now is the same from the time aspect but loading of the net dlls have
> > now disappeared as expected.
> > +++ 8< -----
> >   280   44318 [main] ls 181944 client_request::make_request: cygserver
> > un-availa
> > --- Process 181944 loaded C:\Windows\SysWOW64\advapi32.dll at 75400000
> > --- Process 181944 loaded C:\Windows\SysWOW64\msvcrt.dll at 76CB0000
> > --- Process 181944 loaded C:\Windows\SysWOW64\sechost.dll at 76A00000
> > --- Process 181944 loaded C:\Windows\SysWOW64\rpcrt4.dll at 75300000
> > --- Process 181944 loaded C:\Windows\SysWOW64\sspicli.dll at 750C0000
> > --- Process 181944 loaded C:\Windows\SysWOW64\cryptbase.dll at 750B0000
> > --- Process 181944 thread 186236 created
> > 4525052 4569370 [main] ls 181944 cygheap_user::ontherange: what 2, pw
> > 0x612FFCF0
> >   302 4569672 [main] ls 181944 cygheap_user::ontherange: HOME is already in
> > the
> > --- 8< -----
> > I don't know how the delta time is calculated. As the time lag is always
> > printed after loading the dlls, it may be that the log message is printed
> > after the logged step has been completed. If that is true, the time lag may
> > occur while loading one of the dlls or creating the thread.
> > 
> > As I mentioned before the same command repeated one second again shows
> > normal behaviour (0.406s).
> > +++ 8< -----
> >   106   20307 [main] ls 201132 client_request::make_request: cygserver
> > un-availa
> > --- Process 201132 loaded C:\Windows\SysWOW64\advapi32.dll at 75400000
> > --- Process 201132 loaded C:\Windows\SysWOW64\msvcrt.dll at 76CB0000
> > --- Process 201132 loaded C:\Windows\SysWOW64\sechost.dll at 76A00000
> > --- Process 201132 loaded C:\Windows\SysWOW64\rpcrt4.dll at 75300000
> > --- Process 201132 loaded C:\Windows\SysWOW64\sspicli.dll at 750C0000
> > --- Process 201132 loaded C:\Windows\SysWOW64\cryptbase.dll at 750B0000
> > --- Process 201132 thread 201240 created
> >  9195   29502 [main] ls 201132 cygheap_user::ontherange: what 2, pw
> > 0x612FFCF0
> >    95   29597 [main] ls 201132 cygheap_user::ontherange: HOME is already in
> > the
> > --- 8< -----
> > If you wait a longer period (e.g. 5 minutes), the first (longer) behaviour
> > is shown.
> > As this time lag is not seen with Version 1.7.28 on the same machine, I
> > assume that it has come with Version 2.2.
> 
> Well, it might have been introduced by *any* version later than 1.7.28.
> It's very unlikley that this has been introduced by 2.2.0.  From the
> above output it's not clear where it hangs.  I'll try to reproduce it
> later this week.

Except, I can't.  Under the same circumstances, with nsswitch.conf

  passwd: files
  group: files

and the network connection to my AD disabled, I don't encounter any
noticable lag, not even after waiting a long time to get rid of
potentially cached info.

Any chance this behaviour is triggered by some virus scanner or
something like that?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpGWlgl_KvSG.pgp
Description: PGP signature