Bash wait indefinitely

Brian Ford ford@vss.fsi.com
Tue Dec 2 16:42:00 GMT 2003


On Tue, 2 Dec 2003, Ronald Landheer-Cieslak wrote:
> On Mon, Dec 01, 2003 at 12:24:47PM -0800, Antoine Labour wrote:
> > Ronald Landheer-Cieslak wrote:
> > >Unfortunately, I don't have any system with more than one CPU, so there's
> > >no way I can test it on a system like that and I have not run into any
> > >similar problems on any of the systems I have.. (Cygwin or otherwise).
> > >
I do, and have.  In fact, the problem seemed worse in more recent Cygwin
snapshots.  Although, I have not tested this scenerio in a week or two
now.  And, Thomas Pfaff's 2003-12-01 pthread change might have fixed it.
Could you try a snapshot that includes it?

My dual CPU machine is currently at a trade show and won't be back until
next week.  So, I could help debug, but not until then.

> > >I'm afraid someone else will have to debug this, as I don't see that I can
> > >do anything - especially if it's hard to debug, only happens on multi-CPU
> > >systems and only with complex Bash scripts..
> > If it is the same problem as I am experiencing, it seems to happen on
> > mono-CPU systems as well. Try this simple script :
> >
> > #!/bin/bash
> > i=0
> > while true
> > do
> >     A=$(basename /bin/sh)
> >     i=$(($i+1))
> >     echo $i;
> > done
> >
> OK, I've run the script on my Cygwin machine and it does hang. Attaching with
> strace gets me an access violation (trying to read from NULL). Killing strace
> doesn't kill bash, which tells me it hadn't really attached yet (AFAIK,
> detaching from a process kills the process in all Windows before XP)
>
IIRC, attaching strace via -p pid was broken in 1.5.5.  Either start it
with strace, or try a recent strace/cygwin1.dll.  And, you are correct
about the detach behavior in all but XP.

> > It is true, it's hard to reproduce, like any other race. But if you have
> > any insight about the threading model for processes, and how pipes are
> > handled, regarding synchronisation, that'd be helpful. I'm new to the
> > code base, and the learning curve is kind of steep (especially without
> > having access to cygwin-dev archive).
> Last time I checked, I could download the mbox-format archives from the FTP
> site..
>
> I'm not all that familiar with the Cygwin threading code either, but I'm kinda
> familiar with the Bash codebase (since I'm the Cygwin-Bash maintainer 'n all)
>
> Attaching with gdb to the hanged Bash process gives me the attached gdb.out.
> (HTH)
>
> rlc
>
> BTW: AFAICT this is not a Bash problem: my other Bashes (on Linux)
>      are milling happily..
>
I would tend to agree.  Since we have a simple test case, maybe a "core"
developer could take a quick look.

I'll give it a try as soon as I can get my Cygwin cvs tree to build again.
Recent changes have made this difficult, but I don't have anything solid
to say about it yet.  It could still be just me :^).

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

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



More information about the Cygwin mailing list