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

[L Anderson <lowella at serv dot net>]

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