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: Problem redirecting stderr to pipe in subprocess


On 10/10/2011 6:06 PM, Christopher Faylor wrote:
On Sun, Oct 09, 2011 at 07:58:15PM -0400, Christopher Faylor wrote:
On Sat, Oct 08, 2011 at 05:39:20PM -0400, Ken Brown wrote:
Attached is a slight modification of the STC, in which I set stdin for
the bash subprocess to /dev/null.  With this modification, the program
works as expected (and as on Linux) with cygwin-1.7.9, but the same
problem as before occurs with the latest snapshot.

I can duplicate this problem. I'll take a look.


Thanks for the STC.

As far as I can tell, this is arguably a bug in bash. It's also an annoying compatibility problem between Linux and Cygwin.

When the tty layer in Cygwin was first developed, the model (either in
my head or in reality) was "If you don't have a tty and open a tty, that
becomes your controlling tty".  But, apparently that model changed over
time to something more sensical where you have to explicitly use
ioctl(TIOCSCTTY) to set up a controlling terminal.  On Linux systems
that would presumably be done via login(1).  We don't normally run login
on Cygwin, though.

The problem is that when there is no controlling tty, bash uses a
fallback mechanism to find the name of the tty by opening the tty
associated with fd 0.  It does this without setting the O_NOCTTY
flag and, so, the act of opening the fd assigns a controlling
terminal.

This is not a problem on Linux (or FreeBSD for that matter) but it is a
problem on Cygwin: it causes the aforementioned hang.  So, bash could be
modified to work around this issue but Cygwin is likely the only system
left with this problem.  So, I've modified Cygwin so that a controlling
tty is not assigned if the fd being opened is>  2.  There are still
pathological situations which will cause problems with that but, for
this particular problem, it seems to make bash behave better.

Oh, and the reason why bash was "hanging" is because, thanks to the
intracies of UNIX job control, it had received a SIGTSTP when an attempt
was made to output to a tty for which bash was not the process group
leader

My STCs still don't work right for me under the 2011-10-10 snapshot. The bash subprocess no longer shows as stopped when I run ps, but it doesn't produce any output either, and it doesn't terminate for several minutes. I eventually get the following message on the terminal


1 [main] bash 7604 sig_send: wait for sig_complete event failed, signal -39, rc 258, Win32 error 0

and bash leaves a stackdump. Are you seeing something different? My system is Win7 64-bit in case that's relevant.

Ken

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


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