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] |
Greetings, The RTEMS project has also experienced the configure/expr problem over the last few weeks. A number of people have been working on it, and I would like to present our findings as well as offer a test case that exposes the problem fairly readily. As Igor has deduced in (http://sources.redhat.com/ml/cygwin/2004-08/msg01339.html), the failure mode is an incorrect interpretation of the exit status from invocations of 'expr' in configure.test. The actual call to 'expr' produces the correct output and exit status. When the failure occurs, the appropriate exit status of the 'expr' call is non-zero; however, it is incorrectly interpreted as zero, causing the configure script to exit prematurely. This was evidenced by running the test with the 'expr' wrappered in a script to log the arguments, output and exit status of each 'expr' invocation. This failure is not consistent; it takes many iterations for the effect to be realized. The failure also never occurs if the configure.test script is executed under strace. The failure does not necessarily occur in the same place within the configure script. The failure has not been shown to occur on a native GNU/Linux system to this date. It only occurs on PC/Cygwin systems. As a result, trapping the error typically involves running multiple iterations. Attached, I offer a pair of scripts designed to exhibit the failure. The attached archive contains the following files: configure.test This script was extracted from the RTEMS build enviroment and pared down to avoid requiring the entire build context. It is observed that the failure occurs in the OPTION=VALUE processing of the configure script. test-drive This script invokes configure.test under a variety of iterative and environmental controls. The scripts are suitable for execution in a chroot jail with just the /bin (cp -r /bin /jail/bin) and /tmp (mkdir /jail/tmp), as needed for bash. Execute '$ ./test-drive help' to get details on the options as well as some summary on my current thinking on this. NOTE: it is not uncommon for the script to require on the order of 100 iterations to fail. --- Summary of related threads and investigations performed to date: 1) https://sourceforge.net/tracker/?group_id=2435&atid=102435&func=detail&aid=8 07543 Chris Johns filed a bug (with test scripts) in the MingGW project related to the same configure issue. In that filing, the failure presented under Win98, did not appear to occur in WinXP, and was affected by the order of options listed on the configure command line. 2) http://sources.redhat.com/ml/cygwin/2004-08/msg01025.html Peter Ekberg posted some work within the GGI project, and also posted some links to similar issues found in other projects like Ethereal (circa 09/2003), KimDaBa (04/2004) and Cygwin itself (10/2003). [The latter two quickly degenerated OT, unfortunately...] 3) http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html and http://www.rtems.com/ml/rtems-users/2004/september/msg00036.html Andrew DeFaria summarized a problem in Win32 desktop heap resources (circa 2002) that I initially explored (with brief success on my workstation and Scott Newell's in msg00044.html of that same thread). However, after additional tests and more failure reports, I abandoned that track to concentrate on the expr problem. Nevertheless, manipulating these resources appeared to affect the failure mode with all other things being equal. [I should also mention at this point that it seemed to me that the scripting failures increased in frequency after I killed the Explorer task (which windows promptly respawns). I have not restarted my workstation since that time. In anycase, this may simply be circumstantial] 4) http://sources.redhat.com/ml/cygwin/2002-08/msg00449.html thru http://sources.redhat.com/ml/cygwin/2002-08/msg00556.html This relates to Manfred Spraul's patch for bash related to RECYCLES_PIDS. I have observed the failure to occur under (a)sh, and bash 2.04.5, 2.05b and 3.00.0 ( I compiled them all, including enabling the RECYCLES_PIDS for bash 2.05b ). The one thing I was able to observe was that running under bash 3.00.0 had the least likelyhood of producing the error. However, under long running operations, the exact same failure occurred eventually. [the script above allows easy testing of different shells in chroot jails]. Some details related to my investigation of this can be found here (http://www.rtems.com/ml/rtems-users/2004/september/msg00059.html). I had activated the tracing/logging in (a)sh looking at the modification/use of the global exitstatus and oexitstatus. --- I end with hopes that together the good people of Cygwin and the 'net can come to an understanding of what this thing is. Best Regards, -bogdan p.s. If you should be interested in looking at my cygcheck output get it here: http://www.ngit.com/blog/csb350/cygcheck.txt
Attachment:
configure-test.tar.bz2
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |