1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program

cygwin@alanhowells.e4ward.com cygwin@alanhowells.e4ward.com
Tue Apr 24 12:38:00 GMT 2012


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@motionview3d.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



More information about the Cygwin mailing list