UMN MapServer 4.10 suffers from memory corruption in .NET 2.0 environment.

[ljfong@…]

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.

[scottell]

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.

[tamas]

I think we've done quite some changes to fix the potential memory issues in mapserver and mapscript. I close this ticket now, and one can reopen it if further issues found.