From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14723 invoked by alias); 8 Mar 2012 22:18:51 -0000 Received: (qmail 14707 invoked by uid 22791); 8 Mar 2012 22:18:49 -0000 X-SWARE-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mout.perfora.net (HELO mout.perfora.net) (74.208.4.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Mar 2012 22:18:36 +0000 Received: from JamesJPC (75-146-80-177-Chattanooga.hfc.comcastbusiness.net [75.146.80.177]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LiDX9-1SjjJ32135-00mgI9; Thu, 08 Mar 2012 17:18:35 -0500 From: "James Johnston" To: References: <004e01ccfd70$c69af3f0$53d0dbd0$@motionview3d.com> In-Reply-To: <004e01ccfd70$c69af3f0$53d0dbd0$@motionview3d.com> Subject: RE: Can't reliably redirect standard output from C# program in recent Cygwin Date: Thu, 08 Mar 2012 22:18:00 -0000 Message-ID: <005c01ccfd79$6341f980$29c5ec80$@motionview3d.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-03/txt/msg00298.txt.bz2 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 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@JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ ./HelloCS.exe HelloWorld JamesJ@JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ echo `./HelloCS.exe` JamesJ@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