[Gdal-dev] On Feature.setGeometryDirectly SWIG bindings

[Andrea Aime]

Tamas Szekeres ha scritto:
> 2007/3/18, Andrea Aime <aaime at openplans.org>:
>> Hi,
>> playing with java and OGR I had quite a bit of JVM
>> breakages due to inconsistent/conflicting memory
>> handling on either side of the JNI fence.
>>
>> One that has been tricky to identify is Feature.setGeometryDirectly.
>> This issue is there because every SWIG wrapper
>> does deallocate its C++ counterpart when garbage collected,
>> and thus the OGR Feature that got is geometry thru setGeometryDirectly
>> is left with a dangling reference. (since garbage collection is not
>> predictable, the error may occur a few seconds later, leaving
>> you wondering what went wrong).
>>
> 
> You should implement %typemap() SWIGTYPE *DISOWN for the java binding.
> Every wrapper has an internal flag to denote whether the wrapper owns
> the underlying memory and it's responsible to destroy it.

setGeometryDirectly has that typemap afaik, but it's not working as far
as I can see:

%apply SWIGTYPE *DISOWN {OGRGeometryShadow *geom};
   OGRErr SetGeometryDirectly(OGRGeometryShadow* geom) {
     return OGR_F_SetGeometryDirectly(self, geom);
   }
%clear OGRGeometryShadow *geom;

As soon as I try to use setGeometryDirectly my virtual machine goes
bye bye. Using setGeometry works fine instead.

Both java and c# bindings do have a delete() method that allows
to deallocate the native pointer, and the object finalizers
do call delete() always. I don't see that typemap making any difference
there...

Cheers
Andrea