This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygwin 1.7.15-1 - .NET console output locks up mintty
Greetings, Jamie Briggs!
>> > I have noticed a problem with the "cygwin: The Unix emulation engine" package,
>> > version 1.7.15-1. Output from .NET console does not show up, the console
>> > (mintty) becomes unresponsive and must be killed.
>>
>> > Reverting back to 1.7.14-2 fixes the problem.
>>
>> > The problem can be demonstrated using a HelloWorld.cs containing:
>>
>> > using System;
>>
>> > public class Program
>> > {
>> > static void Main(string[] args)
>> > {
>> > Console.WriteLine("Hello");
>> > }
>> > }
>>
>> > compiling with: csc HelloWorld.cs
>>
>> > and then running: ./HelloWorld.exe
>>
>> > This results in no output and an unresponsive mintty under 1.7.15-1. If
>> > "cmd.exe" is ran on top of bash and then HelloWorld is ran there it does the
>> > same thing. After reverting to 1.7.14-2 everything is working normally again.
>>
>> > I am building the executables with VS2010 and running on 64bit Windows7. I am
>> > attaching my cygcheck.out file.
>>
> Earnie Boyd asked:
>> Does the result change if you install the latest snapshot of
>> cygwin1.dll from cygwin.com/snapshots?
> Yes, replacing cygwin1.dll with the latest snapshot, cywgin1-20120619.dll,
> makes the observed problem go away.
> James Johnson asked:
>> Try both of the following:
>>
>> 1. Update to latest development snapshot, should resolve the bug you are
>> primarily observing.
>> 2. Set the CYGWIN environment variable to pipe_byte. Cygwin now uses
>> message pipes by default, which are not compatible with .NET Framework and
>> Visual C++ runtimes (not currently documented anywhere in Cygwin or MS
>> documentation)
> 1. I'm not sure how to do that.
Run CMD.EXE, say "SET CYGWIN=pipe_byte", run bash -l from the same prompt, and
try to reproduce your issue.
> 2. Running "export CYGWIN=pipe_byte" and then the .NET HelloWorld program still
> exhibited the problem.
The CYGWIN environment variable is a configuration for cygwin1.dll, it's "a bit"
late to define it, when you already have any cygwin1.dll dependent application
running.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 23.06.2012, <01:39>
Sorry for my terrible english...
--
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