Ticket #2023 (closed defect: wontfix)
UMN MapServer 4.10 suffers from memory corruption in .NET 2.0 environment.
|Reported by:||ljfong@…||Owned by:||tamas|
Description: UMN MapServer 4.10 suffers from memory corruption in .NET 2.0 environment when it is custom compiled depending on the compiler used and the platform it runs on. The custom compilation always has the following DLLs and EXEs: - bgd.dll (from gdwin32 package) - libmap.dll (compiled) - mapscript.dll (compiled) - mapscript_csharp.dll (compiled) - mapserv.exe (compiled) In addition to the above DLLs and EXEs, DLLs required for ArcSDE 9.1 connectivity are linked. The following are scenarios where mapserver is compiled and run: Scenario #1: MS Windows XP SP2 (32-bit edition on 32-bit processor) MS Visual Studio 2003 for compiler Result: stable (no memory corruption problem). Scenario #2: MS Windows XP SP2 (32-bit edition on 32-bit processor) MS Visual Studio 2005 SP1 for compiler Result: sporadic memory corruption. Scenario #3: MS Windows Server 2003 R2 (64-bit edition on dual 64-bit processors) MS Visual Studio 2003 for compiler Result: 100% memory corruption. Memory corruption happens as soon as mapObj is created. Scenario #4: MS Windows Server 2003 R2 (64-bit edition on dual 64-bit processors) MS Visual Studio 2005 SP1 for compiler Result: sporadic memory corruption. Scenario #5: Similar to scenario #4, except the fact of the compilation to happen under true 64-bit mode. Not successful done yet. In all cases: - the mapObj is maintained as a member of a managed wrapper class that itself is preserved across ASP.NET page postbacks in session. Small example: Public Class Map Private m_mapObj As mapObj Public Sub New() m_mapObj = new mapObj ... End Sub ... End Class - when access violation happens, the ASP.NET worker thread memory space is corrupted as well. - on sporadic occurences, access violation can happen randomly be that on calling getFilterString() of a layerObj, calling draw() on a mapObj, calling getExpressionString() of a classObj, and so on. Currently considered possible causes of memory corruption: - Different CRT libraries are loaded by different DLLs at run-time. This does not seem to be the case unless dependency walker is not reporting accurate information. - Premature garbage collection that invalidates some or most of references to the unmanaged objects. This seems to be the case as mapObj is preserved across ASP.NET postbacks through session variable. - Multi-threading problem of MapServer in general or the ArcSDE client in particular.
Note: See TracTickets for help on using tickets.