[Mono-bugs] [Bug 71017][Nor] New - P/Invoke methods inside dynamic assemblies don't marshal strings properly
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Wed, 5 Jan 2005 09:11:46 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by jonpryor@vt.edu.
http://bugzilla.ximian.com/show_bug.cgi?id=71017
--- shadow/71017 2005-01-05 09:11:46.000000000 -0500
+++ shadow/71017.tmp.5245 2005-01-05 09:11:46.000000000 -0500
@@ -0,0 +1,118 @@
+Bug#: 71017
+Product: Mono: Runtime
+Version: unspecified
+OS: other
+OS Details:
+Status: NEW
+Resolution:
+Severity:
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: jonpryor@vt.edu
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+Summary: P/Invoke methods inside dynamic assemblies don't marshal strings properly
+
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+
+I'm not sure this is a runtime bug or a class library bug, and
+System.Reflection.Emit isn't a component of either, so flip a coin...
+
+If you use System.Reflection.Emit to create a dynamic assembly which
+contains a P/Invoke method with a string parameter, the string isn't
+marshaled correctly. It isn't marshaled at all, actually -- the UTF-16
+string is passed as-is even when the P/Invoke method is declared as an Ansi
+function.
+
+This used to work on Mono 1.1.1, but now fails on svn-HEAD (revision 38347)
+
+Steps to reproduce the problem:
+1. Compile the following test program: mcs -g srem.cs:
+
+ // file: srem.cs
+ // System.Reflection.Emit P/Invoke Marshaling bug
+ // Works on Mono 1.1.1, fails on svn-HEAD
+ using System;
+ using System.Reflection;
+ using System.Reflection.Emit;
+ using System.Runtime.InteropServices;
+
+ class Test {
+ static MethodInfo CreateGetenv ()
+ {
+ AssemblyName an = new AssemblyName();
+ an.Name = "Support";
+ ModuleBuilder mb = AppDomain.CurrentDomain.DefineDynamicAssembly (an,
+ AssemblyBuilderAccess.Run).DefineDynamicModule (an.Name);
+ TypeBuilder tb = mb.DefineType ("SomeType", TypeAttributes.Public);
+ tb.DefinePInvokeMethod ("getenv", "libc",
+ MethodAttributes.PinvokeImpl | MethodAttributes.Static |
+ MethodAttributes.Public,
+ CallingConventions.Standard,
+ typeof(IntPtr),
+ new Type[]{typeof(string)},
+ CallingConvention.Cdecl,
+ CharSet.Ansi);
+ MethodInfo mi = tb.CreateType ().GetMethod ("getenv");
+ return mi;
+ }
+
+ [DllImport ("libc", CharSet=CharSet.Ansi,
+ CallingConvention=CallingConvention.Cdecl)]
+ static extern IntPtr getenv (string name);
+
+ public static int Main (string[] args)
+ {
+ MethodInfo mi = CreateGetenv ();
+ foreach (string s in args) {
+ IntPtr _dynamic = (IntPtr) mi.Invoke (null, new object[]{s});
+ IntPtr _pinvoke = getenv (s);
+
+ string dynamic = Marshal.PtrToStringAnsi (_dynamic);
+ string pinvoke = Marshal.PtrToStringAnsi (_pinvoke);
+
+ Console.WriteLine ("Environment Variable: '{0}'", s);
+ Console.WriteLine ("\t SRE Value: {0}", dynamic);
+ Console.WriteLine ("\tP/Invoke Value: {0}", pinvoke);
+ }
+ return 0;
+ }
+ }
+
+2. Run the program. You must run this on Unix (it uses getenv(3)):
+
+ mono --debug srem.exe SHELL
+
+Actual Results:
+
+ Environment Variable: 'SHELL'
+ SRE Value:
+ P/Invoke Value: /bin/bash
+
+Expected Results:
+
+ Environment Variable: 'SHELL'
+ SRE Value: /bin/bash
+ P/Invoke Value: /bin/bash
+
+How often does this happen?
+
+Always.
+
+Additional Information:
+
+Note that the value returned by invoking the
+System.Reflection.Emit-generated code is empty. When running under gdb in
+a similar scenario with Mono.Posix, the string that was being passed to
+native code was a UTF-16 string, leading me to assume that when getenv is
+called by the SRE-generated code it's receiving:
+
+ {'S', '\0', 'H', '\0', 'E', '\0', 'L', '\0', 'L', '\0', '\0', '\0'}
+
+This is interpreted as "S", which isn't a valid environment variable, hence
+the null string that's returned.