MapScript C# Memory Corruption Problem (MapServer 4.10)

[Hong]

Update on my progress:

> Since this issue seems to be quite an essential it would be useful to
> keep it tracked through a bug report. Would you submit one by
> summarizing the all the information we currently have
> (http://mapserver.gis.umn.edu/bugs/enter_bug.cgi)? Assign the bug to
> the C# binding.
> 
> Here are some further tests that would worth trying:
> 
> 1. Try to alter the SDE connection pooling behaviour. Adding
> PROCESSING "CLOSE_CONNECTION=DEFER"  would set it on a per layer
> basis. I don't know exactly which would be the best at this case, but
> in fact the connections are retained per threads. Maybe keeping the
> connections alive would affect how often the memory allocations
> related to the connections take place.

Adding this PROCESSING directive seems to have positive effect on 32-bit
platforms. I added the directive to all the layers in the map that are pulled
from SDE database. As a result, I can now compile MapServer using MS Visual
Studio 2005 SP1 on 32-bit machine and have it run without any memory
corruption. As a plus, the rendering of SDE layers seems a little faster as
well after the addition.

Unfortunately, the story is still not the same on 64-bit platform. Memory
corruption still happens just like before. I have tried copying the DLLs
compiled on a 32-bit machine to the 64-bit machine, no success. After that,
following the hint you gave by adding /platform:x86 for the compilation on
64-bit machine, no success either. The 64-bit machine is running Windows
Server 2003 R2 64-bit edition, so everything 32-bit is running under WoW64
emulation. Maybe pInvoke is buggy under WoW64? 

> 2. I've just added a possibility to use a global lock when invoking
> into the mapscript code. To enable this option you should uncomment
> #define USE_GLOBAL_LOCK in csmodule.i. and recompile the mapscript
> code. This setting would ensure that only one thread will invoke into
> libmap.dll in most cases simultaneously, and could help detecting some
> threading issues, though this solution is not equal as restricting the
> invocation to one thread (like the COM STA model would do for
> example).

I obtained updated Makefile.vc and csmodule.i and enabled USE_GLOBAL_LOCK and
recompiled the csharp support. Compilation went succesfully. However, now
MapServer simply takes forever to render anything on the screen, and just hangs
there, classic sign of deadlock.

> 3. Ensure disposing the cloned mapObj explicitly by the "using"
> directive for example, like
> 
> using (map = ((mapObj)Session("m_mapObj")).clone() )
> {
>    // operate on map
> }
> 
> The child references (if any) should also be controlled by an internal
> using blocks. All of the mapscript objects implement IDisposable.

I'm still in the process of modifying my wrapper code to include finalize()
and to have the function body includes a call to dispose() of mapscript
objects.

Hong