UPDATE: RE: bash builtin "test" kills bash on Win 2003 Server R2 x64 (some hardware)

["Stephen Quintero" <stephen at 3tera dot com>]

Hi,

I have now tested four operating systems on four different physical machines:

Windows Server 2003 Standard 32-bit Edition
Windows Server 2003 Standard R2 x64 Edition
Windows Server 2008 Standard 32-bit Edition
Windows Server 2008 Standard 64-bit Edition

Each OS was a clean install with a clean install of cygwin.  All installs were performed in VM's running under Xen 3.2.1 on the first physical machine, an AMD based box, and on this machine the cygwin bash builtin test works under each OS.

I then rsync'd the images to three other machines, each running identical versions of Xen, each with different Xeon based processors.  On these boxes, the bash builtin test fails on the 64-bit OS's, and works on the 32-bit OS's.  To verify, on one of the Xeon boxes, I installed both 64-bit OS's from scratch, in VM's, and then cygwin.  The cygwin postinstall scripts failed because of the broken bash builtin test.

The CPU's are:

#1	Dual-Core AMD Opteron(tm) Processor 2216 HE
#2	Intel(R) Xeon(R) CPU E5320 @ 1.86GHz
#3	Intel(R) Xeon(R) CPU X5355 @ 2.66GHz
#4	Intel(R) Xeon(R) CPU 5130 @ 2.00GHz

Windows 2008 x64 pops up an error message when bash crashes, the contents of which is included in the two attached images (I could not copy and paste in the vnc client).

The problem is dependent on the 64-bit OS / hardware combination (and may relate to the way Xen virtualizes the hardware for HVM guests).  I have no physical access to the machines and am unable to install Windows directly (not under Xen).

That's it.



-----Original Message-----
From: Stephen Quintero 
Sent: Friday, August 08, 2008 11:02 AM
To: cygwin@cygwin.com
Subject: RE: bash builtin "test" kills bash on Win 2003 Server R2 x64 (some hardware)

Thank you for your replies.  Some notes:

"[ -d /bin ]" causes the bash shell to terminate

"/bin/[ -d /bin ]" does not

"/bin/strace.exe [ -d /bin ]" does not cause the shell to terminate, spits out a lot of info, and exits 0x0.

If you refer to the original post by Brian Johnson (http://sourceware.org/ml/cygwin/2008-01/msg00579.html), all of the affects of "test", both builtin and external, which he noted also occur in my test.  I note that he also installed in a Xen VM.

He concludes that "it appears to be an issue with this particular Windows installation".  However, this is not my conclusion.  Why?  Because I have run the self-same VM (an exact block-level copy of the image) on two different sets of hardware, each running identical versions of Xen.  On one machine bash works, on the other it does not.

The problem seems specific to the hardware, or to the way Xen virtualizes the particular hardware (the VM is HVM - no paravirtualized drivers).  

Stephen



-----Original Message-----
From: tmcd@panix.com [mailto:tmcd@panix.com] 
Sent: Thursday, August 07, 2008 11:39 PM
To: cygwin@cygwin.com
Subject: Re: bash builtin "test" kills bash on Win 2003 Server R2 x64 (some hardware)

On Thu, 7 Aug 2008, Larry Hall (Cygwin)
<reply-to-list-only-lh@cygwin.com> wrote:
> But leaving that aside for the moment, perhaps you have a a
> corrupted '/bin/[.exe'.  Yes, it's just a WAG that really shouldn't
> be an issue but given your unique environment, maybe it's worth
> checking.

I don't have the original note handy, but I thought it was of the form
    if [ ... ]
As the subject line noted, [ is a shell builtin in bash (and I think
even in sh of recent decades), so I don't see how it could be affected
by corruption of anything other than /bin/bash.exe.

If the original code was
    if /bin/test ...
or
    if /bin/[ ... ]
then it would be likelier.

-- 
Tim McDaniel; Reply-To: tmcd@panix.com

Attachment: bash-crash1.png
Description: bash-crash1.png

Attachment: bash-crash2.png
Description: bash-crash2.png

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