RFC-24 Mapscript memory management: call for comments

[Umberto Nicoletti]

The following description outlines the problem addressed by item 2.3
of rfc-24 and is taken from a private conversion between me and Tamas.

The scenario is as follows:

we create a new classObj in Java mapscript with following code:

classObj clazz=new classObj(layer);

where layer is a reference to an exisiting layer that is already
associated with a map. The constructor will automatically append the
class to the layer and return the reference to the member. The
swigCMemOwn attribute of the classObj is true.

Now suppose that the user is done with the class, the layer and the
map. At a certain point the gc will kick in and find these three
objects eligible for deallocation. The gc will call their respective
delete methods (destructors). I report the destructor code for the
classObj:

  public void delete() {
    if(swigCPtr != 0 && swigCMemOwn) {
      swigCMemOwn = false;
      mapscriptJNI.delete_classObj(swigCPtr);
    }
    swigCPtr = 0;
  }

and the C (native) code for:

mapscriptJNI.delete_classObj(self) {
        if (!self->layer)
        {
            freeClass(self);
            free(self);
        }
}

First case
=======
collection happens in this order: class, then layer and eventually the map.
No problem will arise as the classObj destuctor will be invoked when
the self->layer reference is still valid and will do nothing.

Second case
==========
collection happens in this order: layer, then map and class.
In this case we have a segfault when the class destructor will
dereference self->layer, because the map destructor has already freed
all the data structures.
Note: the segfault will sometime not happen on my linux box probably
because of my gentoo gcc or the absence of _malloc_check, but it is
nevertheless reproducible.

The solution to this problem is to disown the child element when it is
added to its parent. In this case swigCMemOwn is false and the
destructor will not proceed to call mapscriptJNI.delete_classObj.

I hope this explains the need for 2.3.

Regards,
Umberto