X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=3.9 required=5.0	tests=AWL,BAYES_00,BOTNET,DKIM_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_DKIM_INVALID,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <00e101cd1f09$83405310$89c0f930$@motionview3d.com>
References: <CAHxe11=J=cJnwWcRnA1Pi9CmezWw+z04-b5k4trVmE3mVbiH7A AT mail DOT gmail DOT com> <CAHxe11=DBVftZ15xCLjnaEFYVESqggezJtx2EJNK2ZTUrMUNdQ AT mail DOT gmail DOT com> <00e101cd1f09$83405310$89c0f930$@motionview3d.com>
From: <cygwin AT alanhowells DOT e4ward DOT com>
Date: Tue, 24 Apr 2012 13:37:34 +0100
Message-ID: <CAHxe11=ixmncGgNby3+RZspVQT6DxnFuTbCgH4si=yRk1EhmyQ@mail.gmail.com>
Subject: Re: 1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Reply-To: cygwin AT alanhowells DOT e4ward DOT com
X-e4ward-RCPT: cygwin-cygwin DOT com-cygwin-alanhowells DOT e4ward DOT com-120724-c800-5 AT reply DOT e4ward DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q3OCeQFN006231

Thank you very much James for the helpful comments and pointer to your
sample program.

I have some more information and I tried to minimise .NET and so wrote
the program in C++, compiled with "cl /EHs consoleout.cxx /link"

>>> begin consoleout.cxx
#include <windows.h>

int
main(int argc, char* argv[])
{
    DWORD written;

    // Get standard output file handle
    HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);

    // Do a null write.  This is what .net does.
    WriteFile(h, "", 0, &written, NULL);

    for (int i = 1; i < argc; ++i) {
        DWORD toWrite = strlen(argv[i]);
    	WriteFile(h, argv[i], toWrite, &written, NULL);
    	WriteFile(h, "\n", 1, &written, NULL);
    }

    return EXIT_SUCCESS;
}
<<< end consoleout.cxx

The strange thing here is that I get the issue on the first time (but
not the second or third):
$ ./consoleout hello world | ./readin
$ ./consoleout hello world | ./readin
hello
world
$ ./consoleout hello world | ./readin
hello
world
$

Now one must recompile the consoleout program to get it to fail again.
This bit seems to work intermittently, if it doesn't fail, recompile
the consoleout exe again and then try again.

As a test, I decided to change the readin program to use just windows
API (instead of std::cin and std::cout), compiled with "cl /EHs
readin.cxx /link":

>>> begin readin.cxx
#include <windows.h>

int
main(int argc, char* argv[])
{
    static_cast<void>(argc);
    static_cast<void>(argv);

    HANDLE hi = GetStdHandle(STD_INPUT_HANDLE);
    HANDLE ho = GetStdHandle(STD_OUTPUT_HANDLE);

    char buf[1024];
    DWORD read, written;
    ReadFile(hi, buf, 1024, &read, NULL);
    WriteFile(ho, buf, read, &written, NULL);

    return EXIT_SUCCESS;
}
>>> end readin.cxx

The issue remains:
$ ./consoleout hello world | ./readin
$ ./consoleout hello world | ./readin
hello
world
$ ./consoleout hello world | ./readin
hello
world
$

Hopefully, we have narrowed it down a little further,


Alan

On 20 April 2012 16:23, James Johnston <JamesJ AT motionview3d DOT com> wrote:
> I ran into similar issues, which seemed to be fixed in 1.7.12 - but if you
> are still having issues even on the current Cygwin version of 1.7.13, I'd be
> interested to know if they can be resolved.  If it's anything like the issue
> I found, it has to do with erroneous pipe handling in Cygwin and nothing
> directly to do with .NET.
>
> Have you read this thread yet that I started last month?
> http://sourceware.org/ml/cygwin/2012-03/msg00298.html
>
> The technique I found useful was to use Reflector to decompile the .NET
> Framework's Console class.  You could also refer to the framework's source
> code, which Microsoft has made publicly available (believe it or not!).
> (But for me, decompiled results from Reflector are often faster than trying
> to obtain and then find the exact set of C# source files used to compile the
> class in question.  Also, Reflector provides convenient hyperlinks to jump
> from one related function to another.)
>
> After decompiling, I traced the code so I knew exactly what Win32 API calls
> were being made to read/write the console.  I was then able to isolate and
> reproduce the issue in a straight Win32 app, taking .NET out of the equation
> - which I then posted to the mailing list:
>
> 1.  I simplified C# code to smallest / simplest size possible that still
> reproduces the issue.
> 2.  I decompiled each function call I made to the framework, and followed
> the framework's code to see what API calls it made.  I took notes and made a
> list of API calls that it made in chronological order.
> 3.  Using my notes, wrote a simple C++ program that reproduced the issue.
> 4.  Simplified the C++ program as much as possible while reproducing the
> issue.

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