Mail Archives: cygwin/2012/03/08/17:19:03
Actually, the problem can be reproduced as follows from a C++ console
program. The issue is not specific to .NET. It appears that Cygwin croaks
if you give it a null write (writing zero bytes):
#include <windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
char * test = "AB";
DWORD written;
// Get standard output file handle
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
// Do a null write. This breaks Cygwin when output is redirected.
WriteFile(h, test, 0, &written, NULL);
// Print an "A" and a "B" in two write operations
WriteFile(h, test, 1, &written, NULL);
WriteFile(h, test+1, 1, &written, NULL);
return 0;
}
The correct output of "AB" is not printed when running "echo
`./HelloCPP.exe`" from Cygwin. If you remove the null write (WriteFile of
zero bytes), then Cygwin captures the output of "AB" as expected. Also note
that if the null write is moved between the printing of "A" and the printing
of "B", then the output is also as expected; it seems to be having problems
only when null write is the first write.
How is this related to .NET? It turns out this is the API sequence used
when .NET decides to open standard output:
1. Call GetStdHandle to get standard output file handle.
2. Do a null write to test if the handle was opened successfully. If it
wasn't, then a null stream is used instead of standard output.
There's really no way to disable #2 from a .NET programmer's perspective.
So this new Cygwin appears to have broken every .NET program writing to
standard output, and also every Windows program that does null writes to
standard output.
By the way, maybe these issues exist with standard error. I didn't test.
1. I assume this is a bug in Cygwin. Anything more I should do for
reporting it? (e.g. creating an issue/ticket)
2. Workaround suggestions?
3. Which part of Cygwin do I need to roll back to fix this issue for now?
Best regards,
James Johnston
-----Original Message-----
Sent: Thursday, March 08, 2012 21:17
Subject: Can't reliably redirect standard output from C# program in recent
Cygwin
Hi,
I have had some problems with calling a .NET program written in C# from
Cygwin. I believe it is a bug introduced in recent versions of Cygwin. I
have boiled it down to these simple steps to reproduce:
1. Create a new virtual machine with Windows 7 64-bit RTM installed on it;
don't install any Windows updates. (Note that I have also reproduced it on
a Windows 7 64-bit host machine that is up-to-date on updates. I have not
tried on other versions of Windows.)
2. Create a simple Hello World console application in Visual C# 2008 SP1:
(a) create new console application, (b) add the following line of code to
the Main function:
Console.Write("HelloWorld");
Compile the app as usual; I did the default Debug / Any CPU build.
3. Install Cygwin: go to Cygwin.com, go to the install page and download
the public "setup.exe". Install using defaults: nothing changed, and no
additional packages added.
4. Some test results from the Cygwin prompt:
JamesJ AT JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ ./HelloCS.exe
HelloWorld JamesJ AT JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ echo
`./HelloCS.exe`
JamesJ AT JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $
Here's the problem: the "echo `./HelloCS.exe`" line did NOT print
HelloWorld. Why not? What is going on here - is it a bug in .NET or
Cygwin? My guess is Cygwin... this problem did not occur when I had
previously updated Cygwin in January.
Oddly enough, using "echo `./HelloCS.exe | cat`" works some of the time, but
it's not 100% reliable! Running "./HelloCS.exe | cat" at the terminal
doesn't always work, either.
Are there any changes to the .NET program that could be added to work around
this bug and get the "echo `./HelloCS.exe`" line to work again? Any changes
to Cygwin to make? What package in Cygwin might have introduced this bug
(assuming it is a Cygwin bug) and can I safely roll back my setup to a
working version?
I attached output from cygcheck.out. I also attached my setup.log file.
These files are from my host development workstation that has more than just
the base Cygwin packages installed. Note that I ran setup on Feb 29, 2012.
That is when I first noticed the problem. The previous time I ran setup to
update everything was Jan 18, 2012 - the problem did not exist yet after
that update.
Best regards,
James Johnston
--
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
- Raw text -