Changes between Initial Version and Version 1 of Ticket #1047
- Timestamp:
- 07/24/09 14:40:48 (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1047
- Property Component General → Web API
- Property Milestone → 2.2
- Property Version 2.0.2
-
Ticket #1047 – Description
initial v1 1 There appears to be a bug in the marshalling of unmanaged ANSI strings across the unmanaged/managed boundary in the .NET wrappers due to changes made for RFC 68. This has caused heap corruption issues when the .NET wrappers are called on a product that uses the MapGuide OS code.1 There appears to be a bug in the marshalling of unmanaged ANSI strings across the unmanaged/managed boundary in the .NET wrappers due to changes made for RFC 68. This has caused heap corruption issues when the .NET wrappers are called on a product that uses the !MapGuide OS code. 2 2 3 MapGuide RFC 68 can be found here:3 !MapGuide RFC 68 can be found here: 4 4 5 5 http://trac.osgeo.org/mapguide/wiki/MapGuideRfc68 … … 13 13 readily evident in heap corruption assertions on 64-bit platforms, but should 14 14 also be present in 32-bit platforms. The heap corruptions occurred at startup 15 of the product using MapGuide OS code via the .NET API and would result in the product failing to successfully start.15 of the product using !MapGuide OS code via the .NET API and would result in the product failing to successfully start. 16 16 17 In the submission, the following methods were added to MgObject:17 In the submission, the following methods were added to !MgObject: 18 18 19 {{{ 19 20 virtual char* GetMultiByteClassName(); 20 21 virtual char* GetNameSpace(); 22 }}} 21 23 22 24 These methods returned a string with the class name or name space. On the … … 24 26 getclassid.code: 25 27 28 {{{ 26 29 DllExport char* getClassName(void* ptrObj) 27 30 { … … 33 36 return ((MgObject*)ptrObj)->GetNameSpace(); 34 37 } 38 }}} 35 39 36 40 These methods are exported from the unmanaged DLL and called from the managed … … 38 42 like this: 39 43 44 {{{ 40 45 [DllImport("unmanagedDllName", EntryPoint="getClassName")] 41 46 public static extern string getClassName(IntPtr objectRef); … … 43 48 [DllImport("unManagedDllName", EntryPoint="getNameSpace")] 44 49 public static extern string getNameSpace(IntPtr objectRef); 50 }}} 45 51 46 52 The problem occurs because the DLLImport mechanism doesn't marshall the char * … … 62 68 void/IntPtr to the managed wrapper. The code now looks like this: 63 69 70 {{{ 64 71 DllExport void* getClassName(void* ptrObj) 65 72 { … … 75 82 return jresult; 76 83 } 84 }}} 77 85 78 86 (similar changes to getNameSpace) 79 87 80 88 The return type should also be changed on the managed side DLLImports from string to 81 IntPtr:89 !IntPtr: 82 90 91 {{{ 83 92 [DllImport("unManagedDllName", EntryPoint="getClassName")] 84 93 public static extern IntPtr getClassName(IntPtr objectRef); … … 86 95 [DllImport("unManagedDllName", EntryPoint="getNameSpace")] 87 96 public static extern IntPtr getNameSpace(IntPtr objectRef); 97 }}} 88 98 89 Since the getClassName and getNameSpace functions now return IntPtr, the99 Since the getClassName and getNameSpace functions now return !IntPtr, the 90 100 createObject overload that took these two values as parameters needed to be 91 101 modified to match the type. In addition, code was added to createObject to … … 93 103 release the shared memory buffer: 94 104 105 {{{ 95 106 static public object createObject(int id, IntPtr nameSpaceNamePtr, IntPtr 96 107 classNamePtr, IntPtr cPtr, bool ownMemory) … … 106 117 107 118 ... 119 }}} 108 120 109 121 A patch file with the proposed fixes is attached to this ticket.
