public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-02-27 16:54 Andres Martinelli
  2012-02-28 14:15 ` Corinna Vinschen
  0 siblings, 1 reply; 20+ messages in thread
From: Andres Martinelli @ 2012-02-27 16:54 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Cygwin,

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits).

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5.

How to reproduce:

1) Compile the example with
         csc bug.cs

     The c# compiler (csc), can be usually found in
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception.

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions.

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0.

Best regards,
Andrés Martinelli


[-- Attachment #2: bug.cs --]
[-- Type: text/plain, Size: 447 bytes --]

using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;

class Program {
  static void Main(string[] args) {
    XmlSerializer serializer = new XmlSerializer(typeof(Simple));
  }
}

public class Simple : IXmlSerializable {
  #region IXmlSerializable Members
  public XmlSchema GetSchema() { return null; }
  public void ReadXml(XmlReader reader) { }
  public void WriteXml(XmlWriter writer) { }
  #endregion
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-03-12 19:51 James Johnston
  2012-03-13 19:58 ` David Sastre Medina
  0 siblings, 1 reply; 20+ messages in thread
From: James Johnston @ 2012-03-12 19:51 UTC (permalink / raw)
  To: cygwin

I have also noticed this issue; again it was with the XML serialization functions like Andres Martinelli originally noted.  The root of the problem is that Windows environment variables are not case sensitive, while they *are* in a Unix environment.  Cygwin passes an environment block with duplicate identically-named variables (if case insensitive; unique if case sensitive), and this will make some Windows programs go boom, because they assume the block is maintained in a case-insensitive manner.

Here's a full stack trace:

Unhandled Exception: System.ArgumentException: Item has already been added. Key in dictionary: 'tmp'  Key being added: 'tmp'
   <cut>
   at System.Collections.Specialized.StringDictionary.Add(String key, String value)
   at System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated(SafeUserTokenHandle userToken, String cmd, String currentDir, TempFileCollection tempFiles, String& outputName, String& errorName, String trueCmdLine)
   <cut>
   at Microsoft.CSharp.CSharpCodeGenerator.Compile(CompilerParameters options, String compilerDirectory, String compilerExe, String arguments, String& outputFile, Int32& nativeReturnValue, String trueArgs)
   <cut>
   at System.Xml.Serialization.XmlSerializer..ctor(Type type)

You can see that the XML serializer needs to invoke the C# compiler to dynamically compile some code.  The compiler needs to place all environment variables in a case-insensitive dictionary (since that's how things are done on Windows!).  Decompiling System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated gives this:

        StringDictionary sd = new StringDictionary();
        foreach (DictionaryEntry entry in Environment.GetEnvironmentVariables())
        {
            sd.Add((string) entry.Key, (string) entry.Value);
        }

Note that StringDictionary is case insensitive, according to the docs: "The key is handled in a case-insensitive manner; it is translated to lowercase before it is used with the string dictionary."  So that's why it crashes.

The big problem as I see it is that Cygwin, out-of-the-box, creates an environment block that violates a basic assumption of Windows programs - that the environment block is not case sensitive.  I don't know what the solution should be, but it's not this.

From /etc/profile:

tmp=$(cygpath -w "$ORIGINAL_TMP" 2> /dev/null)
temp=$(cygpath -w "$ORIGINAL_TEMP" 2> /dev/null)
TMP="/tmp"
TEMP="/tmp"

This code is what causes the crash, by creating these "duplicate" (from a Windows perspective) keys.

I would guess that any Windows program that tries to do case-insensitive lookups in the environment is liable to crash.  At the very least, it won't necessarily give you the answer you expect (if both "TEMP" and "temp" store different values and you do a case insensitive lookup of "TeMp", which is going to be returned if you don't crash?)

James

--- Original message ---

Hi Cygwin, 

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits). 

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5. 

How to reproduce: 

1) Compile the example with 
         csc bug.cs 

     The c# compiler (csc), can be usually found in 
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe 
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe 

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception. 

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions. 

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0. 

Best regards, 
Andrés Martinelli 


using System.Xml; 
using System.Xml.Schema; 
using System.Xml.Serialization; 

class Program { 
  static void Main(string[] args) { 
    XmlSerializer serializer = new XmlSerializer(typeof(Simple)); 
  } 
} 

public class Simple : IXmlSerializable { 
  #region IXmlSerializable Members 
  public XmlSchema GetSchema() { return null; } 
  public void ReadXml(XmlReader reader) { } 
  public void WriteXml(XmlWriter writer) { } 
  #endregion 
}


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

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-03-01 18:49 Matt Seitz (matseitz)
  0 siblings, 0 replies; 20+ messages in thread
From: Matt Seitz (matseitz) @ 2012-03-01 18:49 UTC (permalink / raw)
  To: cygwin

"Corinna Vinschen" wrote news:
> On Mar  1 10:16, Matt Seitz (matseitz) wrote:
> > 
> > Here's another thought:  is the problem only with the "/home"
directory
> > that Cygwin setup creates (ex: /cygdrive/c/cygwin/home)?  If so,
would
> > it be possible to only modify that original "/home" directory, and
not
> > whatever directory "/home" might now point to?
> 
> If you have the inheritable default permissions set as the getfacl
> tests, then you should be glad if this gets changed, regardless
whether
> this is the same /home that setup created.

OK, fair enough.  I just thought it might be safer or "more polite" for
Setup to not change permissions which Setup didn't set in the first
place, or that the user might have explicitly set.  And, of course, the
user always has the option to change the permissions back again if they
really want them.


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

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-03-01 18:17 Matt Seitz (matseitz)
  2012-03-01 18:41 ` Corinna Vinschen
  0 siblings, 1 reply; 20+ messages in thread
From: Matt Seitz (matseitz) @ 2012-03-01 18:17 UTC (permalink / raw)
  To: cygwin

"Corinna Vinschen" wrote:
> 
> Maybe it's better if the code tests the permissions first, along these
> lines:

Thanks.  I would feel better with a solution that doesn't change my
permissions if they don't really need to be changed.

Here's another thought:  is the problem only with the "/home" directory
that Cygwin setup creates (ex: /cygdrive/c/cygwin/home)?  If so, would
it be possible to only modify that original "/home" directory, and not
whatever directory "/home" might now point to?



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

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-02-29 22:47 Matt Seitz (matseitz)
  2012-03-01 10:09 ` Corinna Vinschen
  0 siblings, 1 reply; 20+ messages in thread
From: Matt Seitz (matseitz) @ 2012-02-29 22:47 UTC (permalink / raw)
  To: cygwin

"Corinna Vinschen" wrote:
> 
> David, instead of setting tmp/temp, What about adding the following
line
> to /etc/profile?
> 
>   setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run
/var/tmp 2>/dev/null

Will that cause problems if I have:

$ mount | grep home
C:/Documents and Settings on /home type ntfs (binary)
$ getfacl /home
# file: /home
# owner: Administrators
# group: Domain Users
user::rwx
group::---
group:SYSTEM:rwx
group:Users:r-x
group:Power Users:r-x
mask:rwx
other:r-x
default:user::rwx
default:user:Administrators:rwx
default:group::---
default:group:SYSTEM:rwx
default:group:Users:r-x
default:group:Power Users:r-x
default:mask:rwx
default:other:r-x
$


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

^ permalink raw reply	[flat|nested] 20+ messages in thread
* 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
@ 2012-02-27 16:12 Andres Martinelli
  0 siblings, 0 replies; 20+ messages in thread
From: Andres Martinelli @ 2012-02-27 16:12 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Cygwin,

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits).

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5.

How to reproduce:

1) Compile the example with
         csc bug.cs

     The c# compiler (csc), can be usually found in
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception.

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions.

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0.

Best regards,
Andrés Martinelli


[-- Attachment #2: bug.cs --]
[-- Type: text/plain, Size: 447 bytes --]

using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;

class Program {
  static void Main(string[] args) {
    XmlSerializer serializer = new XmlSerializer(typeof(Simple));
  }
}

public class Simple : IXmlSerializable {
  #region IXmlSerializable Members
  public XmlSchema GetSchema() { return null; }
  public void ReadXml(XmlReader reader) { }
  public void WriteXml(XmlWriter writer) { }
  #endregion
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-03-13 19:58 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-27 16:54 1.7.10/1.7.11: .Net programs started from a cygwin console may fail Andres Martinelli
2012-02-28 14:15 ` Corinna Vinschen
2012-02-28 14:18   ` Jon Clugston
2012-02-28 14:50     ` Corinna Vinschen
2012-02-28 21:42       ` David Sastre Medina
2012-02-28 23:05         ` Corinna Vinschen
2012-02-29  9:42           ` Corinna Vinschen
2012-02-29  1:36       ` Andrey Repin
2012-02-29  9:47         ` Corinna Vinschen
2012-02-29 12:39           ` Andrey Repin
2012-02-29 12:49             ` Earnie Boyd
2012-02-29 14:51               ` Corinna Vinschen
  -- strict thread matches above, loose matches on Subject: below --
2012-03-12 19:51 James Johnston
2012-03-13 19:58 ` David Sastre Medina
2012-03-01 18:49 Matt Seitz (matseitz)
2012-03-01 18:17 Matt Seitz (matseitz)
2012-03-01 18:41 ` Corinna Vinschen
2012-02-29 22:47 Matt Seitz (matseitz)
2012-03-01 10:09 ` Corinna Vinschen
2012-02-27 16:12 Andres Martinelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).