On Nov 25 22:01, Marco Atzeri wrote:
> 
> 
> On 25/11/2015 12:03, Marco Atzeri wrote:
> >On 25/11/2015 08:06, Thomas Wolff wrote:
> >>Am 24.11.2015 um 23:29 schrieb Marco Atzeri:
> >>>
> >
> >>>...
> >>>I assume it is an interaction with mintty.
> >>Many problems of that kind attributed to mintty are actually problems
> >>with cygwin or especially pty.
> >>Please test also with another terminal (xterm, rxvt, ...).
> >>Also some more details could be helpful as I cannot reproduce the issue
> >>(output of `type ping`, actual host pinged).
> >>------
> >>Thomas
> >
> >you are right is not a mintty only issue.
> >Same happens in xterm
> >
> >
> >$ which ping
> >/usr/bin/ping
> >
> >$ ping 2.2.2.2
> >PING 2.2.2.2 (2.2.2.2): 56 data bytes
> >
> >It sticks here forever, CTRL+C ineffective.
> >Process Explorer or Task Manager are needed to kill the process.
> >Also kill -9 PID is ineffective
> >
> >On the old cygwin.bat (aka windows cmd)
> >CTRL+C is effective
> >
> >  64 $ ping 2.2.2.2
> >PING 2.2.2.2 (2.2.2.2): 56 data bytes
> >
> >----2.2.2.2 PING Statistics----
> >2 packets transmitted, 0 packets received, 100.0% packet loss
> 
> 
> the problem seems restricted to the 64bit test version of cygwin.

I think this is pure coincidence.  After some hours debugging this
problem it seems it's a race condition, architecture-independent and
present since quite a while in Cygwin.  In case of ping the race leads
to a blocking socket function missing a signal arrived, thus the
signal is never handled.  This in turn blocks the next signal from being
delivered.

I have a potential fix, but I have to test it a bit.  The signal code
is pretty complicated...


Corinna

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