This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]