Subject: 1.5.10: expr + configure failure + testcase
From: "Bogdan Vacaliuc" <[email-masked]>
To: <[email-masked]>
Cc: "'RTEMS Users'" <[email-masked]>
Date: Sat, 11 Sep 2004 03:05:01 -0400

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