UMN MapServer 4.10 suffers from memory corruption in .NET 2.0 environment.
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.
Change History
(6)
Severity: |
normal → critical
|
Owner: |
changed from szekerest to tamas
|
Cc: |
ljfong@sdf.lonestar.org → ljfong@sdf.lonestar.org,
|
Cc: |
ljfong@sdf.lonestar.org, → ljfong@sdf.lonestar.org
|
Resolution: |
→ wontfix
|
Status: |
new → closed
|
We (MapDotNet Server) have dealt with memory corruption issues in similar contexts. Our resolution is to maintain a single mapObj instance for all our needs and use locks to prevent concurrent access. My hunch is that there are multi-threaded issues with mapserver/mapscript.
I have also had problems with running on a 64-bit Windows (Vista). I experienced the same behavior as scenario #3. My solution was to enable WOW emulation on IIS (this is 32-bit emulation for .NET). This worked, but I would end up getting crashes of IIS when mapserver/mapscript would have an error.