Problem redirecting stderr to pipe in subprocess

[Ken Brown]

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