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]

Re: Bash 3.1.17(9) $ <at> Expansion error


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]