This is the mail archive of the
mailing list for the Cygwin project.
Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).
- From: L Anderson <lowella at serv dot net>
- To: cygwin at cygwin dot com
- Date: Sun, 06 Feb 2011 20:40:30 -0800
- Subject: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ).
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
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
any file with an absolute name longer than PATH_MAX, such as
If so, leave fail as 0, because the current working directory
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;
if (PATH_MAX <= cwd_len && cwd_len < PATH_MAX + DIR_NAME_SIZE)
c = getcwd (buf, PATH_MAX);
if (!c && errno == ENOENT)
fail = 11;
if (c || ! (errno == ERANGE || is_ENAMETOOLONG (errno)))
fail = 21;
if (dotdot_max <= cwd_len - initial_cwd_len)
if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
c = getcwd (buf, cwd_len + 1);
if (! (errno == ERANGE || errno == ENOENT
|| is_ENAMETOOLONG (errno)))
fail = 22;
if (AT_FDCWD || errno == ERANGE || errno == ENOENT)
fail = 12;
if (c && strlen (c) != cwd_len)
fail = 23;
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple