X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: Bash 3.1.17(9) $ <at>  Expansion error
Date: Wed, 20 Dec 2006 14:54:50 +0000 (UTC)
Lines: 54
Message-ID:  <loom.20061220T154523-487@post.gmane.org>
References:  <Pine DOT LNX DOT 4 DOT 61 DOT 0612200025490 DOT 29171 AT mtfhpc DOT demon DOT co DOT uk>  <4588BF49 DOT 1000607 AT byu DOT net> <Pine DOT LNX DOT 4 DOT 61 DOT 0612201048070 DOT 30142 AT mtfhpc DOT demon DOT co DOT uk>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Note-from-DJ: This may be spam

Mark Fortescue <mark <at> mtfhpc.demon.co.uk> writes:

> 
> Hi Eric,
> 
> The mensioned problems are unique to cygwin. The $ <at>  expansion error is 
not 
> present in cygwin bash-3.0-14.tar.bz2
> 
> For re-preduction, see the Nov 6th email.

> > Test case: Download and unpack CSSC-1.0.1.
> > Enter the following commands:
> > cd CSSC-1.0.1                   # Change dir if required
> > ./configure -enable-binary
> > make
> > make check

Telling me to download and build a random tarball is not a testcase (at least, 
not a simple enough test case that I am willing to do).  Give me a few lines I 
can type into a terminal.  In other words, extract out the bug from the build, 
into something much smaller and reproducible.  Or ask the CSSC folks to help 
narrow down your testcase, since the failure is occurring while building their 
package.

> The memory issues are reported by a windows popup reporting that 
> application sh.exe has tried to write to memory that it is not alowd to. 
> It gives the instruction address and the memory address but I did not make 
> a note of them as I was trying to prepare a system to alow me to do some 
> work on somthing else. The system is an Intel system with WinXP Home. On 
> my now defunct AMD XP Pro system, I had a number of sudden blue screens 
> where I was unable to read any details before automatic reboot, that only 
> occoured when using bash scripts under cygwin. The blue screens may just 
> have been a coincidence as the IDE chip died. Having un-installed cygwin 
> and gone back to a Feb 2005 release (bash 2.05) the issue is nolonger 
> present. When I have the time, I will upgrade bash on its own to 3.0-14 
> and redo the test to see if it is a cygwin bash-3 issue or a cygwin core 
> system error. If it is, I will note the details and pass them on.

I highly doubt that it is a bash error, rather I suspect a hardware error or 
buggy driver.  Those types of issues tend to manifest themselves more 
frequently in bash due to bash's prevelant use within cygwin, as well as bash's 
fork-heavy approach to life compared to many other cygwin apps (most buggy 
drivers tend to expose their bugs during the cygwin forking process).  Are you 
sure you are not running a culprit driver, such as Agnitum Outpost, McAfee 
virus scan, Logitech webcam, ...?  I'm not completely ruling out bash, but 
knowing the faulty address is still useful, to see if it lands within the 
virtual memory ranges normally used by bash or by cygwin, or if it lands within 
kernel memory managed by a faulty driver that happened to do some execution 
during bash's thread.

-- 
Eric Blake



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