MapScript C# Memory Corruption Problem (MapServer 4.10)

[Hong]

An update for my progress:

After calling clone() before calling draw() of mapObj, MapServer became more
stable, but under heavier load (many more dynamic layers and config), the
memory corruption still happened.

The strange solution I had found was to compile MapServer using Visual Studio
2003 instead of 2005. After doing so, MapServer no longer suffered memory
corruption. For some reason, the binary produced from VS2003 running under
.NET 2.0 did not have any memory management problem. This was done with the
mapObj still being maintained through session. 

After a lot of brainstorming over this, I have come to the conjecture that the
garbage collector in the .NET framework might have been the culprit of the
memory corruption. Since MapServer internal objects are managed internally via
PInvoke, they are unmanaged as far as the garbage collector is concerned.
Somehow between ASP.NET page postbacks, the garbage collector came in and
invalidated the references unmanaged objects prematurely, as they are not
referenced by any managed object. Now, objects compiled for .NET 1.1 (vs 2003)
are somehow treated differently by the garbage collector of .NET 2.0. I don't
know the exact mechanism. There are ways to control the garbage collector,
however I would rather not explore them.

I would like to hear any other thoughts/comments.

Hong

On Mon, Jan 22, 2007 at 10:39:38PM -0700, Hong wrote:
> I have reopened the bug report.
> 
> On Mon, Jan 22, 2007 at 11:12:39PM +0100, Tamas Szekeres wrote:
> > 2007/1/22, Hong <ljfong at sdf.lonestar.org>:
> > >
> > >Now instead of using the mapObj stored in the session, I perform a clone()
> > >on the mapObj from the session, and use the clone to perform draw(). So 
> > >far, I
> > >have not seen any crash after doing this. The only problem I observed was 
> > >that
> > >the symbol transparencies was messed up after subsequent clone + draw. 
> > >Maybe
> > >the clone is not perfect, I'm not sure.
> > >
> > 
> > That seems strange. You should describe the problem in more detail and
> > reopen the following bug then:
> > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=931
> > 
> > Please attach the corresponding mapfile, the symbol definition file
> > and the symbol image to this bug.
> > 
> > Best Regards,
> > 
> > Tamas