[vtkusers] Java vtk wrapper memory/garbage collection issues.

Luke Dodd luke.dodd at gmail.com
Tue Dec 15 17:21:05 EST 2009


Hi,

I'm having a number of issues with memory management/garbage
collection of vtk objects when using the Java wrappers. The issues
broadly fall under early deletion, although the second issue seems
more subtle than this. I think they could be linked so I'll keep them
both in one message.

Firstly I think I have uncovered a bug, or at least behaviour I didn't
expect. When (in Java code) a vtkAlgorthmOutput is held, but the
corresponding vtkAlgorithm java wrapper object that it came from no
longer has any references to it (for example goes out of scope) the
vtkAlgorithm has it's Delete() method called upon java garbage
collection/finalization. The issue is that after this the native
vtkAlgorithm object seems to deleted. So if something tires to use the
vtkAlgorithmOutput this will in turn probably mean trying to access
the vtkAlgorthm which is now gone (for example on pipeline execution).
I would have thought the vtkAlgorithmOutput instance would hold a
reference (register itself) to the corresponding vtkAlgorithm instance
as far as vtk's memory management concerned. Below I have included a
minimal example of this:


// the following code segfaults regularly for me on Ubuntu 9.10 64bit,
vtk cvs or 5.2.4
import vtk.vtkAlgorithm;
import vtk.vtkAlgorithmOutput;
import vtk.vtkGeometryFilter;
import vtk.vtkPolyDataMapper;

public class GCError {
static
       {
               System.loadLibrary("vtkCommonJava");
               System.loadLibrary("vtkFilteringJava");
               System.loadLibrary("vtkIOJava");
               System.loadLibrary("vtkImagingJava");
               System.loadLibrary("vtkGraphicsJava");
               System.loadLibrary("vtkRenderingJava");
               System.loadLibrary("vtkFilteringJava");
       }


public static vtkAlgorithmOutput method(vtkAlgorithm algorithm){
       vtkGeometryFilter gf2 = new vtkGeometryFilter();
       gf2.SetInputConnection(algorithm.GetOutputPort());
       // Uncommenting this "fixes it"
       //gf2.SetReferenceCount(gf2.GetReferenceCount()+1);
       return gf2.GetOutputPort();
}

public static void main(String[] args) throws InterruptedException {
       // loob block seems to crash about 50% of the time, loop 100 times to
make sure it does
       for(int i = 0; i < 100; i++){
               //create a filter chain of gf1 and gf2, let gf2
vtkAlgorithm go out of scope
               vtkGeometryFilter gf1 = new vtkGeometryFilter();
               vtkAlgorithmOutput gf2o =  method(gf1);

               // force a GC/finalize, if this is not here the code runs fine.
               System.gc();
               System.runFinalization();

               // attempt to use gf2 via it's output port.
               vtkPolyDataMapper mapper = new vtkPolyDataMapper();
               mapper.SetInputConnection(gf2o);
       }
}
}

Is this indeed a bug or am I doing something silly? Should I file a
report and attempt to fix it? (I did find a similar issue posted on
this list a while back and someone asked for a minimal example)

To get around the above issue in my code I have made sure to hold
vtkAlgorithm objects, not vtkAlgorithmOutputs. Now I'm having a
problem when vtkAlgorithm's native object instances  are cleaned up by
vtk's (not Java's) garbage collector (the gui on the application
allows the user to effectively completely change much of filter
"pipeline", so plenty of vtkAlgorithms need to be
allocated/freed/connected/mapped). To complicate matters the Delete()
that starts the garbage collection is called from the finalizer of a
Java wrapper object calling Delete() on the native object. My code
generally crashes with this assert:

java: /home/luke/work/myvtk/cvs-041209/VTK/Common/vtkGarbageCollector.cxx:699:
void vtkGarbageCollectorImpl::CollectComponent(vtkGarbageCollectorImpl::ComponentType*):
Assertion `(*e)->Object->GetReferenceCount() == 1' failed.

Here is a screen shot of a DDD session on a coredump of the assert:
http://imgur.com/0yF34.png (this seems to say that the value the
assert is testing _is_ 1 !)

The code, crashed, at the same point and gave a double free error -
but I didn't catch a core dump for that one.

I'm thinking something to do with circular references and the way the
Java wrapper simply bumps up the reference count? But I really don't
know what the heck is going on. Any ideas of what's causing this? Even
enough of a hint or information about vtk GC to attempt to reproduce
this in a minimal example would be great! The good news is that this
one seems to only happen very infrequently when I garbage
collection/finalization is initiated after lots of creation, mapping
and deleting of filters (for the purposes of debugging my application
this garbage collection initiation is started with a large button
labelled "crash" :-)

I've also come across this issue: http://public.kitware.com/Bug/view.php?id=8942
Which adds to my worries about vtk/java memory problems.

Also I have to ask are any other people having this much trouble with
the Java wrappings? Should I even be trying to use them for a fairly
big large piece of code?

Thanks,

Luke Dodd



More information about the vtkusers mailing list