[vtkusers] Java vtk wrapper memory/garbage collection issues.
Cory Quammen
cquammen at cs.unc.edu
Tue Dec 15 22:04:35 EST 2009
Luke,
Did you experience this error with a recent CVS checkout? If so, I'm
not sure what's wrong.
However, if you experienced this problem with VTK 5.2.4 only, then I
would recommend updating to VTK 5.4 or CVS head. We had problems
similar to yours in our Java+VTK apps. Jeff Baumes at Kitware did some
excellent work in the Java wrappings within the last year or so that
seem to have fixed up our early deletion problems.
Cory
On Tue, Dec 15, 2009 at 5:21 PM, Luke Dodd <luke.dodd at gmail.com> wrote:
> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
--
Cory Quammen
Center for Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen
More information about the vtkusers
mailing list