Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[L Anderson]

While trying to diagnose another problem, I decided to build the 
'coreutils' package so I could check a few things out.  I followed the 
'coreutils' build instructions...'cygport coreutils-8.8-1 all' and 
things went swimmingly up to the point where the messages displayed read:
	...
	checking whether getnameinfo is declared... (cached) yes
	checking for struct addrinfo... yes
	checking whether getcwd handles long file names properly...
	
After waiting a good bit, it appeared progress had stop.  Not wanting to 
interrupt the build, I left to do other things.  Long story short, on my 
return, more than 6 hours later, there was no visible signs of 
progress--no new messages displayed.

Digging a bit deeper, I found the build process was still running and in 
the following chunk of code in 'conftest.c'--doing 'mkdir'--so I killed 
the sucker.

<code>
   while (1)
     {
       size_t dotdot_max = PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN);
       char *c = NULL;

       cwd_len += DIR_NAME_SIZE;
       /* If mkdir or chdir fails, it could be that this system cannot 
create
          any file with an absolute name longer than PATH_MAX, such as 
cygwin.
          If so, leave fail as 0, because the current working directory 
can't
          be too long for getcwd if it can't even be created.  For other
          errors, be pessimistic and consider that as a failure, too.  */
       if (mkdir (DIR_NAME, S_IRWXU) < 0 || chdir (DIR_NAME) < 0)
         {
           if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
             fail = 20;
           break;
         }

       if (PATH_MAX <= cwd_len && cwd_len < PATH_MAX + DIR_NAME_SIZE)
         {
           c = getcwd (buf, PATH_MAX);
           if (!c && errno == ENOENT)
             {
               fail = 11;
               break;
             }
           if (c || ! (errno == ERANGE || is_ENAMETOOLONG (errno)))
             {
               fail = 21;
               break;
             }
         }

       if (dotdot_max <= cwd_len - initial_cwd_len)
         {
           if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
             break;
           c = getcwd (buf, cwd_len + 1);
           if (!c)
             {
               if (! (errno == ERANGE || errno == ENOENT
                      || is_ENAMETOOLONG (errno)))
                 {
                   fail = 22;
                   break;
                 }
               if (AT_FDCWD || errno == ERANGE || errno == ENOENT)
                 {
                   fail = 12;
                   break;
                 }
             }
         }

       if (c && strlen (c) != cwd_len)
         {
           fail = 23;
           break;
         }
       ++n_chdirs;
     }
</code>

Further investigation showed the code really had been running and had 
created a chain of more than 1300 'confdir3' sub-directories under the 
sub-directory 'build'. I then ran 'cygport coreutils-8.8-1 finish' which 
took at least 12 hours more to clean up the mess. (It would have taken 
somewhat less time had I known to disable AVG.)

Since I couldn't control the build process, I wrote a test script to 
emulate the 'confdir3' sub-directory chain's creation and deletion 
behavior to better understand what was going on.  My conclusion is that 
the above code is a bit "nasty".  I've further found that the code is 
even more "nefarious" when run with 'AVG Internet Security 2011' enabled.

The running time of my emulation script, with 'AVG' disabled, is long 
but almost linear; with 'AVG' enabled, it's much much longer and closer 
to polynomial time of order around 10--at least in the range of 0-1000 
sub-directories (a1x + a2x^2 + a3x^3 + a4x^4 + a5x^5 + a6x^6 + a10x^10, 
with the appropriate selected ais, x=subdir level).

I then run 'cygport coreutils-8.8-1 prep' to verify my findings.  I 
killed it after a few hours and 1336 'confdir3' subdirs later.  I'm 
finishing off now with 'cygport coreutils-8.8-1 finish' to clean things 
up. It's been at it for a few hours now--quite a few yet to go, I 
suspect.  Yes! I'm satisfied; it's definitely a "nasty" bit of code.  (I 
think it should be removed or fixed to behave better.)

Therefore, for those with 'AVG Internet Security 2011', my advice is to 
disable AVG before doing a coreutils build (or any other using 
cygport?).  You may still have to wait a long time, but not nearly as 
long as if it's enabled!  I suspect similar behavior will be had with 
other anti-viri programs--YMMV.

In regards to the aforementioned while loop in 'conftest.c'--the logic 
of it being run for every invocation of a 'coreutils' build escapes me. 
I can see running it once per OS, outside of the build process, to 
determine if the given OS does the right thing; after that, shouldn't it 
just be a case of checking if the OS being used has been tested and 
deemed to behave properly?

This may be just a case of pilot error that I can't see because, surely, 
others must have encountered this situation before.  Perhaps someone 
would be so kind as to enlighten me on this and tell me what I'm missing.

NB: My 'XPProSP3' 'cygwin' installation is up to snuff--the latest as of 
now, 'cygcheck -c' shows all OK, 'coreutils' build prerequisites 
installed, etc.


Thanks,

Lowell Anderson






--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[David Arnstein]

My experience with AVG was very good, as long as I disabled all of its
continuous protection features. I mean, I just used it as a scanner.
Cygwin worked fine for me in this arrangement.

I switched to Microsoft's free MSE because it is good enough for my
purposes. But I did not find AVG to be bad.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[Vincent Rivière]

L Anderson wrote:
> This may be just a case of pilot error that I can't see because, surely,
> others must have encountered this situation before.

I can't say for sure, but recently I had big suspicions about AVG and 
directories.

I have an MFC testsuite for some software unrelated to Cygwin. It 
creates a temporary directory, creates some files in it, then delete it 
recursively. This had always worked perfectly on all machines. But 
recently, some time after installing AVG, the deletion of the temp dir 
failed with a sharing violation. Strangely, trying to delete that 
directory 2 times in a row almost fixed the problem.

I should try to uninstall AVG to see if this problem goes away.

-- 
Vincent Rivière

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On 02/06/2011 09:40 PM, L Anderson wrote:
> In regards to the aforementioned while loop in 'conftest.c'--the logic
> of it being run for every invocation of a 'coreutils' build escapes me.
> I can see running it once per OS, outside of the build process, to
> determine if the given OS does the right thing; after that, shouldn't it
> just be a case of checking if the OS being used has been tested and
> deemed to behave properly?

Yes, this particular configure test takes a long time, even without
virus scanning, on WinXP (where Microsoft has an O(n^2) implementation);
it's faster on newer Windows (where Microsoft fixed things to be O(n)).

You can pre-seed a config.site cache to skip the test by using a known
outcome result (in fact, I do just that when building coreutils):

$ cat >> /usr/config.site <<\EOF
# configure gets the right answer, but only after hammering the system
gl_cv_func_getcwd_path_max=yes
EOF

I suppose I should also tweak my coreutils*.cygport file to pre-seed the
cache at configure time (by adding gl_cv_func_getcwd_path_max=yes to
CYGCONF_ARGS), but that won't help you when upgrading to
coreutils-8.10-1.cygport, which came out between your report against 8.8
and this email.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[L Anderson]

Vincent Rivière wrote:
> L Anderson wrote:
>> This may be just a case of pilot error that I can't see because, surely,
>> others must have encountered this situation before.
>
> I can't say for sure, but recently I had big suspicions about AVG and
> directories.
>
> I have an MFC testsuite for some software unrelated to Cygwin. It
> creates a temporary directory, creates some files in it, then delete it
> recursively. This had always worked perfectly on all machines. But
> recently, some time after installing AVG, the deletion of the temp dir
> failed with a sharing violation. Strangely, trying to delete that
> directory 2 times in a row almost fixed the problem.
>

In all my testing, I have never encountered any thing like a share 
violation.  However, to reconfirm AVG greatly extends the time required 
to recursively traverse a directory tree, look at the following results 
of my test.  I create then delete a chain of 150 sub-directories 
recursively.  The times given are for 10 consecutive operations.  The 
first set is with AVG enabled, the second with it disabled.  As you can 
see, the enabled times are nonlinear, while the disabled ones are, for 
the most part, linear (153 seconds vs 22 seconds!).  I only show 150 
levels because any thing much larger is unbearable.


Regards,

LA


-----Test with AVG enabled-------
$ testCygport.sh  -d "O:\ScsiU2WAVGEnabled" -t both -m 150
$testFlag:
$createFlag:  create
$deleteFlag:  delete
$basePath:  /cygdrive/o/ScsiU2WAVGEnabled
$modVal:   10
$maxDepth: 150

(mkdir/cd) confdir3(0):0 sec.--decending
(mkdir/cd) confdir3(10):1 sec.--decending
(mkdir/cd) confdir3(20):1 sec.--decending
(mkdir/cd) confdir3(30):1 sec.--decending
(mkdir/cd) confdir3(40):2 sec.--decending
(mkdir/cd) confdir3(50):2 sec.--decending
(mkdir/cd) confdir3(60):2 sec.--decending
(mkdir/cd) confdir3(70):3 sec.--decending
(mkdir/cd) confdir3(80):3 sec.--decending
(mkdir/cd) confdir3(90):5 sec.--decending
(mkdir/cd) confdir3(100):6 sec.--decending
(mkdir/cd) confdir3(110):8 sec.--decending
(mkdir/cd) confdir3(120):9 sec.--decending
(mkdir/cd) confdir3(130):12 sec.--decending
(mkdir/cd) confdir3(140):14 sec.--decending
Made or traversed 150 sub-directories in 69 seconds.
***Starting the accent, removing sub-directories***
(cd/rmdir) confdir3(140):31 sec.--accending
(cd/rmdir) confdir3(130):14 sec.--accending
(cd/rmdir) confdir3(120):11 sec.--accending
(cd/rmdir) confdir3(110):9 sec.--accending
(cd/rmdir) confdir3(100):7 sec.--accending
(cd/rmdir) confdir3(90):6 sec.--accending
(cd/rmdir) confdir3(80):5 sec.--accending
(cd/rmdir) confdir3(70):4 sec.--accending
(cd/rmdir) confdir3(60):3 sec.--accending
(cd/rmdir) confdir3(50):2 sec.--accending
(cd/rmdir) confdir3(40):2 sec.--accending
(cd/rmdir) confdir3(30):1 sec.--accending
(cd/rmdir) confdir3(20):2 sec.--accending
(cd/rmdir) confdir3(10):1 sec.--accending
(cd/rmdir) confdir3(0):1 sec.--accending
Back at depth level 0; deleted 150 sub-directories.
Decent 69 seconds; accent 84 seconds; total 153 seconds.

-----Test with AVG disabled---------
$ testCygport.sh  -d "O:\ScsiU2WAVGDisabled" -t both -m 150
$testFlag:
$createFlag:  create
$deleteFlag:  delete
$basePath:  /cygdrive/o/ScsiU2WAVGDisabled
$modVal:   10
$maxDepth: 150

(mkdir/cd) confdir3(0):0 sec.--decending
(mkdir/cd) confdir3(10):1 sec.--decending
(mkdir/cd) confdir3(20):0 sec.--decending
(mkdir/cd) confdir3(30):1 sec.--decending
(mkdir/cd) confdir3(40):0 sec.--decending
(mkdir/cd) confdir3(50):1 sec.--decending
(mkdir/cd) confdir3(60):1 sec.--decending
(mkdir/cd) confdir3(70):1 sec.--decending
(mkdir/cd) confdir3(80):0 sec.--decending
(mkdir/cd) confdir3(90):1 sec.--decending
(mkdir/cd) confdir3(100):1 sec.--decending
(mkdir/cd) confdir3(110):1 sec.--decending
(mkdir/cd) confdir3(120):0 sec.--decending
(mkdir/cd) confdir3(130):1 sec.--decending
(mkdir/cd) confdir3(140):0 sec.--decending
Made or traversed 150 sub-directories in 9 seconds.
***Starting the accent, removing sub-directories***
(cd/rmdir) confdir3(140):2 sec.--accending
(cd/rmdir) confdir3(130):1 sec.--accending
(cd/rmdir) confdir3(120):1 sec.--accending
(cd/rmdir) confdir3(110):1 sec.--accending
(cd/rmdir) confdir3(100):0 sec.--accending
(cd/rmdir) confdir3(90):1 sec.--accending
(cd/rmdir) confdir3(80):1 sec.--accending
(cd/rmdir) confdir3(70):1 sec.--accending
(cd/rmdir) confdir3(60):1 sec.--accending
(cd/rmdir) confdir3(50):1 sec.--accending
(cd/rmdir) confdir3(40):1 sec.--accending
(cd/rmdir) confdir3(30):1 sec.--accending
(cd/rmdir) confdir3(20):1 sec.--accending
(cd/rmdir) confdir3(10):0 sec.--accending
(cd/rmdir) confdir3(0):1 sec.--accending
Back at depth level 0; deleted 150 sub-directories.
Decent 9 seconds; accent 13 seconds; total 22 seconds.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[L Anderson]

Eric Blake wrote:
> On 02/06/2011 09:40 PM, L Anderson wrote:
>> In regards to the aforementioned while loop in 'conftest.c'--the logic
>> of it being run for every invocation of a 'coreutils' build escapes me.
>> I can see running it once per OS, outside of the build process, to
>> determine if the given OS does the right thing; after that, shouldn't it
>> just be a case of checking if the OS being used has been tested and
>> deemed to behave properly?
>
> Yes, this particular configure test takes a long time, even without
> virus scanning, on WinXP (where Microsoft has an O(n^2) implementation);
> it's faster on newer Windows (where Microsoft fixed things to be O(n)).
>
> You can pre-seed a config.site cache to skip the test by using a known
> outcome result (in fact, I do just that when building coreutils):
>
> $ cat>>  /usr/config.site<<\EOF
> # configure gets the right answer, but only after hammering the system
> gl_cv_func_getcwd_path_max=yes
> EOF
>

Thanks for the hint--it allowed me to by-pass the test.  However, for 
the record, based on 'coreutils-8.10-1--configure[3295,3296]', I think 
you meant:

 > $ cat>>  /usr/share/config.site<<\EOF
 > # configure gets the right answer, but only after hammering the system
 > gl_cv_func_getcwd_path_max=yes
 > EOF

xor

 > $ cat>>  /usr/etc/config.site<<\EOF
 > # configure gets the right answer, but only after hammering the system
 > gl_cv_func_getcwd_path_max=yes
 > EOF

Correct?

I used the latter and it did the trick.

Regards,

LA


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On 02/14/2011 10:13 PM, L Anderson wrote:
> Thanks for the hint--it allowed me to by-pass the test.  However, for
> the record, based on 'coreutils-8.10-1--configure[3295,3296]', I think
> you meant:
> 
>> $ cat>>  /usr/share/config.site<<\EOF
>> # configure gets the right answer, but only after hammering the system
>> gl_cv_func_getcwd_path_max=yes
>> EOF

Yes, autoconf looks for share/config.site relative to the --prefix
argument, so /usr/share/config.site is the right place for a config.site
that affects cygport builds.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]