[mapguide-internals] Memory leakage in WebTier (Java)

[Andreas Morf]

Walt,
Indeed it doesn't - in both cases: the layerDefContent object is not owned by java (ie. swigCMemOwn=false because it is provided by
C++ layer by ::GetReader) so just the java object is destroyed and no delete-call is made to the C++ layer.
But even if the MgByteReader-C++ object would have been destroyed, I cannot see (in the code) where the final reference to the 'src'
C++ object is released and 'src' is destroyed...

Andreas


> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org]
> On Behalf Of Walt Welton-Lair
> Sent: Thursday, September 02, 2010 4:06 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] Memory leakage in WebTier (Java)
> 
> Why should the GC order matter at all?
> 
> - case 1: src gets GC'ed first, followed by layerDefContent
>         When the src gets GC'ed the ref count of the associated C++ object drops back to one - no C++
> objects are yet destroyed.  Then when the layerDefContent object gets GC'ed the ref count for its C+
> object goes to zero and it gets destroyed, which in turn will release the final reference to the src
> C++ object and it will also get destroyed.
> 
> - case 2: layerDefContent gets GC'ed first, followed by src
>         When the layerDefContent gets GC'ed the ref count for its C+ object goes to zero and it gets
> destroyed, and the ref count of the src C++ object drops back to one.  Then when the src object gets
> GC'ed the ref count for the src C+ object goes to zero and it also gets destroyed.
> 
> 
> It seems like some of the managed objects are not getting GC'ed, which in turn is causing the
> underlying C++ objects to not be destroyed.
> 
> Walt
>