[Mono-bugs] [Bug 61134][Maj] Changed - GCHandle.AddrOfPinnedObject gives incorrect address

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Mon, 5 Jul 2004 07:14:35 -0400 (EDT)

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 dge@softec.st.


--- shadow/61134	2004-07-05 06:54:24.000000000 -0400
+++ shadow/61134.tmp.27969	2004-07-05 07:14:34.000000000 -0400
@@ -3,21 +3,20 @@
 Version: unspecified
 OS: unknown
 OS Details: 
 Status: NEW   
 Severity: Unknown
-Priority: Normal
+Priority: Major
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: mathpup@mylinuxisp.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
-Summary: GCHandle.AddrOfPinnedObject gives incorrect address for arrays
+Summary: GCHandle.AddrOfPinnedObject gives incorrect address
 Description of Problem: 
 When a GCHandle with GCHandleType.Pinned is created, it should be possible 
 to obtain the address of the object with GCHandle.AddrOfPinnedObject(). 
 When the object in question is an array, Mono appears to return a pointer 
@@ -106,6 +105,66 @@
 ------- Additional Comments From dge@softec.st  2004-07-05 06:54 -------
 Created an attachment (id=8453)
 Csharp only test case, not limited to arrays
+------- Additional Comments From dge@softec.st  2004-07-05 07:14 -------
+As the testcase attached above shows (use -unsafe to compile), the
+problem is not limited to arrays (so I fix the Summary), but is true
+for all kind of objects, either primitive, built-in or custom.
+It seems that mono provide the core address of the object in memory,
+not the starting address of its data members. For arrays, it is also
+more complex since it also have to hide the length member. For other
+object, the offset is generally 8 bytes from the address expected.
+I have also noted, that for a class (not struct) without an explicitly
+LayoutKind, MS.NET throw an System.ArgumentException: Object contains
+non-primitive or non-blittable data, and mono does not. You can see
+that by removind the LayoutKind of the class TestClass in my testcase.
+For your lasyness, here his the result of the testcase, under both
+MS.NET and Mono (I have put "...?...?...?" in MS.NET out of bound
+bytes showed due to my +8 that helps in some sizes illustrate the mono
+bug, since the ones of MS.NET are obviously undetermined) :
+Mono results:
+MS.NET and expected results: