Re: resuming backgrounded job causes hang (Cygwin 1.7.19 / Dothan 1.7GHz)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun  6 13:02, Corinna Vinschen wrote:
> On Jun  6 11:04, Seb.Th wrote:
> > Le 06/06/2013 08:25, Sumudu Fernando a Ãcrit :
> > 
> > >I'm having a weird issue in 1.7.19.  As per the subject line, when I
> > >try to resume a backgrounded job, I get a hang (after bash echoes the
> > >job name).  I couldn't find anything about this in the list archives,
> > >possibly because it may be limited to specific architectures (more
> > >below).
> > >
> > >simple testcase from a fresh terminal (I'm using the default mintty, with bash)
> > >$ ls | less
> > ><CTRL-Z to background less>
> > >$ fg
> > >
> > >whereupon bash echoes the job name (in my case "ls -hF --color=tty |
> > >less -r") and then nothing happens (no response to input AFAICT)
> > >
> > >Interesting things:
> > >- this only happens on my (ancient) laptop (this is why I mentioned
> > >the processor in the subject line) -- it *does not* happen on my
> > >desktop machine (which is a Q6600, nearly ancient now I suppose).
> > >- Windows task manager shows the process I tried to resume at high CPU
> > >usage, and if I kill it from there ("end process") bash recovers fine
> > >- I can open a separate cygwin terminal and see the "ls" in the output
> > >of ps.  It does *not* have an "S" beside it to indicate a suspended
> > >process.  "kill" does nothing, "kill -9" hangs (until I kill via task
> > >manager).
> > >
> > >I attached cygcheck output; I did get some errors (that are in the
> > >file also) but I don't know what they actually mean (if anything).
> > >
> > >FWIW, this did not happen with 1.7.17 (I skipped 1.7.18).
> > 
> > This problem seems to be very similar to the thread "Bash sub-shell
> > freezing in Midnight Commander".
> > 
> > Something went wrong after 1.7.17 (or its dependencies ?)
> 
> This is signal stuff which is usually cgf's domain and he's not
> available for another couple of days.
> 
> I can reproduce this, however, and I'm trying to find a fix.  Stay
> tuned.

Ok, I found the reason for this behaviour.  There was a potential
starvation problem which really only got hold on single-CPU/single
core systems.  Two threads were locking a mutex and waiting for each
other.  The one thread which could have resolved the problem never got
CPU time due to the locking mechanism and an extremly tight window in
which the other thread unlocked the mutex.

I fixed the problem in CVS and I've just created a new 2013-06-06 32 bit
developer snapshot, which you can find on http://cygwin.com/snapshots/,
as well as a 64 bit DLL 1.7.20-1 which I uploaded as part of the 64 bit
test distro.

Please test and send feedback.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple