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

http://bugzilla.ximian.com/show_bug.cgi?id=61134

--- 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   
 Resolution: 
 Severity: Unknown
-Priority: Normal
+Priority: Major
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: mathpup@mylinuxisp.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
-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:
+byte[]:
+[0][44][62][1][0][0][0][0][0][0][0][0][25][0][0][0][1][2][3][4][5][6][7][8][9]
+string:
+[248][119][169][0][0][0][0][0][26][0][0][0][65][0][66][0][67][0][68][0][69][0][7
+0][0][71][0][72][0][73][0][74][0][75][0][76][0][77][0][78][0][79][0][80][0][81][
+0][82][0][83][0][84][0]
+int:
+[136][129][169][0][0][0][0][0][255][255][0][0]
+long:
+[40][41][62][1][0][0][0][0][255][255][0][0][0][0][0][0]
+IntPtr:
+[0][42][62][1][0][0][0][0][255][255][0][0]
+CustomClass:
+[192][42][62][1][0][0][0][0][127][0][0][0][255][255][0][0]
+CustomStruct:
+[32][43][62][1][0][0][0][0][127][79][62][1][255][255][0][0]
+CustomStruct:
+[144][43][62][1][0][0][0][0][0][0][0][0][0][0][0][0]
+
+MS.NET and expected results:
+byte[]:
+[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][
+23][24][25]
+string:
+[65][0][66][0][67][0][68][0][69][0][70][0][71][0][72][0][73][0][74][0][75][0][76
+][0][77][0][78][0][79][0][80][0][81][0][82][0][83][0][84][0][85][0][86][0][87][0
+][88][0][89][0][90][0]
+int:
+[255][255][0][0]...?...?...?
+long:
+[255][255][0][0][0][0][0][0]...?...?...?
+IntPtr:
+[255][255][0][0]...?...?...?
+CustomClass:
+[127][0][0][0][255][255][0][0]...?...?...?
+CustomStruct:
+[127][0][0][0][255][255][0][0]...?...?...?
+CustomStruct:
+[0][0][0][0][0][0][0][0]...?...?...?
+