[Gdal-dev] On Feature.setGeometryDirectly SWIG bindings

Tamas Szekeres szekerest at gmail.com
Sun Mar 18 12:42:43 EDT 2007


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.

Since the SWIG java and C# implementation is somewhat similar, you can
look into swig_csharp_extensions.i for a possible implementation. It
must be noted that there are some other issues to be handled related
to the memory management and garbage collection. Most of the problems
were handled for C# in the file mentioned before.
I'm a bit disappointed that these issues are not handled officially by
the SWIG implementation.

> That function has no special handling... as is, it should
> be removed from the bindings of any language that has
> garbage collection and finalization to avoid memory
> handling issues.
>

This is not the only function to be handled this way. It would be
unwise to remove them all.


> The following chapters in the Swig guide:
> http://www.swig.org/Doc1.3/CSharp.html#csharp_memory_management_objects
> http://www.swig.org/Doc1.3/Java.html#java_memory_management_objects
> seem to provide a solution for that issue, other than removing
> the method.
>

That proposal is not general (implementation specific) so it would
require large amount of coding when applying it for the various
gdal/ogr classes.

Best regards,

Tamas



More information about the Gdal-dev mailing list