From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3439 invoked by alias); 7 Feb 2011 04:40:07 -0000 Received: (qmail 3428 invoked by uid 22791); 7 Feb 2011 04:40:06 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_YG X-Spam-Check-By: sourceware.org Received: from sitemail3.everyone.net (HELO imta-38.everyone.net) (216.200.145.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Feb 2011 04:39:59 +0000 Received: from pps.filterd (omta004 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p174dYY6029241 for ; Sun, 6 Feb 2011 20:39:58 -0800 Received: from dm0205.mta.everyone.net (sj1-slb03-gw2.sj2.proofpoint.com [172.16.1.96]) by imta-38.everyone.net with ESMTP id ua9th00mf-1 for ; Sun, 06 Feb 2011 20:39:58 -0800 X-Eon-Dm: dm0205 Received: by dm0205.mta.everyone.net (EON-AUTHRELAY2 - ae18b8cb) id dm0205.4d4ce10f.328f95 for ; Sun, 6 Feb 2011 20:39:57 -0800 X-Eon-Sig: AQMb1uJNT3edIVpF9gIAAAAB,284115f29c5cc0d5321521df74a88cec Message-ID: <4D4F77BE.4000305@serv.net> Date: Mon, 07 Feb 2011 04:40:00 -0000 From: L Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Please add 'AVG Internet Security 2011' to the BLODA list (and cygport also :-) ). Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1102060201 X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-02/txt/msg00164.txt.bz2 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. 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; } 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