Re: 1.7.10 : output from .NET programs does not get through pipeline

Re: 1.7.10 : output from .NET programs does not get through pipeline

[David Kerrawn]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

I too have noticed this problem or a variation of it. I've narrowed it down
to the change in pipe behavior in snapshot cygwin-src-20111023

Specifically in http://cygwin.com/snapshots/winsup-diffs-20111022-20111023
+	 Note that the write side of the pipe is opened as
PIPE_TYPE_MESSAGE.
+	 This *seems* to more closely mimic Linux pipe behavior and is
+	 definitely required for pty handling since fhandler_pty_master
+	 writes to the pipe in chunks, terminated by newline when CANON mode
+	 is specified.  */
     r = CreateNamedPipe (pipename, PIPE_ACCESS_INBOUND | overlapped,
-			   PIPE_TYPE_BYTE | PIPE_READMODE_BYTE, 1, psize,
+			   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE, 1, psize,

I took a copy of the 20111023 snapshot source and compiled cygwin1.dll,
copied it to cygwin1.dll-message, patched the source back to the
PIPE_TYPE_BYTE, recompiled and copied cygwin1.dll to cygwin1.dll-byte.

Running a sample test case (attached), the output from any .NET application
that I tried (eg MSBuild.exe) caused the pipe to close and I'd get no
output. Non .NET applications like "cmd.exe /c ver" worked fine with both
dlls.

Importantly for me, if a program such as make is called where the
MSBuild.exe is called from the Makefile not only is there no output from the
MSBuild.exe command but the entire command tree resulting from the pipe
exits immediately without any error or exception.

Workarounds in the other posts to get the .NET application to even run
including piping the output to another command loses the return code from
the application or the output.

My current workaround of recompiling cygwin1.dll from source with
PIPE_TYPE_BYTE currently seems to work but it's probably going to cause
other problems further down the line as this patch included some explanatory
text stating why it is necessary.

Regards

David






[-- Attachment #2: safeopen.pl --]
[-- Type: application/octet-stream, Size: 712 bytes --]

#!/usr/bin/perl
use strict;
use warnings;
use POSIX ":sys_wait_h";
# make STDOUT flush immediately
$| = 1;

my $cmd;
$cmd = "/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5/MSBuild.exe -version";
run_cmd($cmd);
$cmd = "/cygdrive/c/WINDOWS/SYSTEM32/cmd.exe /c ver";
run_cmd($cmd);

sub run_cmd {
    my ($program) = @_;
	print "\nRunning command: $program\n";
	my $pid = open(KID_TO_READ, "-|");
	defined($pid) || die "can't fork: $!";
	if ($pid) { # parent
		while (<KID_TO_READ>) {
			print $_;
		}
		close(KID_TO_READ) || warn "kid exited $?";
	} else { # child
		#($EUID, $EGID) = ($UID, $GID); # suid only
		exec($program,)
		|| die "can't exec program: $!";
		# NOTREACHED
	}
}

[-- Attachment #3: safeopen-output.txt --]
[-- Type: text/plain, Size: 1002 bytes --]

===== Incorrect Output =====
C:\cygwin\bin>copy cygwin1.dll-message cygwin1.dll
Overwrite cygwin1.dll? (Yes/No/All): y
        1 file(s) copied.

build@build06 ~
$ perl safeopen.pl

Running command: /cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5/MSBuild.exe -v
ersion

Running command: /cygdrive/c/WINDOWS/SYSTEM32/cmd.exe /c ver

Microsoft Windows XP [Version 5.1.2600]

build@build06 ~
$ exit

===== Correct Output =====
C:\cygwin\bin>copy cygwin1.dll-byte cygwin1.dll
Overwrite cygwin1.dll? (Yes/No/All): y
        1 file(s) copied.

build@build06 ~
$ perl safeopen.pl

Running command: /cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5/MSBuild.exe -v
ersion
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3625]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

3.5.30729.1
Running command: /cygdrive/c/WINDOWS/SYSTEM32/cmd.exe /c ver

Microsoft Windows XP [Version 5.1.2600]

build@build06 ~
$ exit

[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

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

Re: 1.7.10 : output from .NET programs does not get through pipeline

[Christopher Faylor]

On Mon, Mar 26, 2012 at 05:00:02PM +0100, David Kerrawn wrote:
>I too have noticed this problem or a variation of it. I've narrowed it down
>to the change in pipe behavior in snapshot cygwin-src-20111023

Are you saying that this is still broken in recent snapshots?  A fix for
this went in on March 12.

cgf

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

RE: 1.7.10 : output from .NET programs does not get through pipeline

[David Kerrawn]

> On Mon, Mar 26, 2012 at 05:00:02PM +0100, David Kerrawn wrote:
> >I too have noticed this problem or a variation of it. I've narrowed it
> down
> >to the change in pipe behavior in snapshot cygwin-src-20111023
> 
> Are you saying that this is still broken in recent snapshots?  A fix
> for
> this went in on March 12.
> 
> cgf
> 

cgf,
I'm sorry, you are correct. The 20120312 and later snapshots work fine.
My searches were only on .NET 1.7.10 and I failed to notice the subject
change.
Plus I should have tried the later snapshots.

Many thanks.

Regards
David.



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

Re: 1.7.10 : output from .NET programs does not get through pipeline

[Edgar Ellis]

> Hi all,
>
> I started observing some very strange effects when launching .NET
> programs from cygwin, after upgrading to version 1.7.10.
> The example below is using the MSBuild.exe as an example, but I get
> analogous results with any console program compiled for .NET.
> One can see that each pipeline  works normally exactly once. The
> second time the pipe does not bring anything.
> I do not know if it is possible to reset it; killing all cygwin
> processes and logging off apparently does not help.
>
> $  MSBuild.exe -version
> Microsoft (R) Build Engine Version 3.5.30729.1
> [Microsoft .NET Framework, Version 2.0.50727.3625]
> Copyright (C) Microsoft Corporation 2007. All rights reserved.
>
> 3.5.30729.1
>
> $ MSBuild.exe -version | head -1
> Microsoft (R) Build Engine Version 3.5.30729.1
>
> $ MSBuild.exe -version | head -1
>
> $ MSBuild.exe -version | wc
>       4      20     177
>
> $ MSBuild.exe -version | wc
>       0       0       0
>

Hi,

I hit the same issue with msbuild and was able to work around it by 
doing a pipe in cmd.exe, eg:

$ cmd.exe '/c' 'msbuild.exe -version' | wc
       0       0       0

$ cmd.exe '/c' 'msbuild.exe -version | cat' | wc
       4      20     183



- Edgar


> One program that surprisingly does not get broken so easily is "perl"
>
> $ MSBuild.exe -version   | perl -ne print | wc
>       4      20     177
>
> $ MSBuild.exe -version   | perl -ne print | wc
>       4      20     177
>
> Output from normal DOS, windows and cygwin programs is not affected.
>
> Output redirection with ">" works as usual.
>
> Command substitution with $(  ) or ` ` does not work if the output
> comes from .NET program:
>
> $ echo +++ `MSBuild /help` +++
> +++ +++
>
> $ echo +++ `MSBuild.exe /help>tmp.tmp ; dos2unix tmp.tmp; head tmp.tmp` +++
> dos2unix: converting file tmp.tmp to Unix format ...
> +++ Microsoft (R) Build Engine Version 3.5.30729.1 [Microsoft .NET
> Framework, Version 2.0.50727.3625] Copyright (C) Microsoft Corporation
> 2007. All rights reserved. Syntax: MSBuild.exe [options] [project
> file] Description: Builds the specified targets in the project file.
> If a project file is not specified, MSBuild searches the current
> working directory for a file that has a file extension that ends in
> "proj" and uses that file. +++
>
> I get similar results on other computers running Windows XP, Vista and
> 7 with 1.7.10 installed, but not with 1.7.9.
>
> Have you seen anything like this? How can it be fixed?
>
> Regards
> Ilya Beylin


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

1.7.10 : output from .NET programs does not get through pipeline

[Ilya Beylin]

Hi all,

I started observing some very strange effects when launching .NET
programs from cygwin, after upgrading to version 1.7.10.
The example below is using the MSBuild.exe as an example, but I get
analogous results with any console program compiled for .NET.
One can see that each pipeline  works normally exactly once. The
second time the pipe does not bring anything.
I do not know if it is possible to reset it; killing all cygwin
processes and logging off apparently does not help.

$  MSBuild.exe -version
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3625]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

3.5.30729.1

$ MSBuild.exe -version | head -1
Microsoft (R) Build Engine Version 3.5.30729.1

$ MSBuild.exe -version | head -1

$ MSBuild.exe -version | wc
      4      20     177

$ MSBuild.exe -version | wc
      0       0       0

One program that surprisingly does not get broken so easily is "perl"

$ MSBuild.exe -version   | perl -ne print | wc
      4      20     177

$ MSBuild.exe -version   | perl -ne print | wc
      4      20     177

Output from normal DOS, windows and cygwin programs is not affected.

Output redirection with ">" works as usual.

Command substitution with $(  ) or ` ` does not work if the output
comes from .NET program:

$ echo +++ `MSBuild /help` +++
+++ +++

$ echo +++ `MSBuild.exe /help>tmp.tmp ; dos2unix tmp.tmp; head tmp.tmp` +++
dos2unix: converting file tmp.tmp to Unix format ...
+++ Microsoft (R) Build Engine Version 3.5.30729.1 [Microsoft .NET
Framework, Version 2.0.50727.3625] Copyright (C) Microsoft Corporation
2007. All rights reserved. Syntax: MSBuild.exe [options] [project
file] Description: Builds the specified targets in the project file.
If a project file is not specified, MSBuild searches the current
working directory for a file that has a file extension that ends in
"proj" and uses that file. +++

I get similar results on other computers running Windows XP, Vista and
7 with 1.7.10 installed, but not with 1.7.9.

Have you seen anything like this? How can it be fixed?

Regards
Ilya Beylin

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