[vtkusers] Re: VTK Java Wrapper - Crashes vs. Leaks

[David E DeMarle]

Hello,

Yes there is a bug in Java wrapped VTK such that memory does eventually
become exhausted. My change a few months back caused this, but was necessary
to prevent normal object accesses from randomly causing crashes.

>Questions:
>1. Are they any modifications somewhere else in the VTK library in order
>to prevent the above leaking?

Unfortunately I do not know of any effective and simple solutions.

>2. If not, do you have any suggestions/advices to guide us around the
>above problem by making a change in VTK itself or in our application?

In c++ applications, every vtkObject::New must be matched with a
corresponding vtkObject::Delete(), either manually or within
vtkSmartPointers. I would recommend doing something similar, but that
programming style is not well supported by Java, and my initial attempts at
trying it were unsuccessful.

2.1 Do you have any plan to fix the leakage problem or does it require a
major change in VTK?

Currently no one at Kitware is working on it. Solving it properly would
likely require more research time than any of our projects have allocated to
Java development. I would be more than happy to help apply, test and commit
any solutions that the community at large comes across.

Sincerely,
Dave DeMarle

On 8/28/07, Francois Delisle <francois.delisle at intelerad.com> wrote:
>
> Mr Demarle,
>
> We are using VTK from our Java application and we are suffering from
> random crashes in the JNI layer while calling it.
> After investigation and reading various posts from VTK's developer
> mailing list, we confirmed that we are suffering from the same crash as
> described in
> http://public.kitware.com/pipermail/vtkusers/2007-June/091451.html
>
> As the post mentions, VTK uses global weak references, if running with
> JNI version 1.2, in the vtkPointerLookup hashtable. Thus, these
> references don't prevent the objects from being collected by Java's
> Garbage collector.
>
> Now considering the Object destruction flow:
> Java GC
> -> vtkObjectBase.finalize()
>   -> vtkObjectBase.VTKDelete() (native) // eventually frees the native
> object with a call to "delete this"
>      -> vtkJavaUtils.vtkJavaDeleteObject( jobject )              // read
> object id from java object field and acquire/release mutex
>         -> vtkJavaUtils.vtkJavaDeleteObjectFromHash( ... )
>
> It is possible that while code executes in the JNI Layer, Java's GC
> collects the Java object (if not strongly referenced anymore) which
> eventually deletes the native instance. As a consequence, pointers
> returned by vtkJavaUtils.vtkJavaGetPointerFromObject() may return a
> pointer to garbage, right?
>
> We are using VTK version 4.2.6. This version include cvs revision 1.48
> of vtkJavaUtils.cxx.
> We saw that you made a change in vtkJavaUtils, between revision 1.59 and
> 1.60, in order to avoid the use of global weak references in order to
> avoid the above problem.
> (
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkJavaUtil.cxx?r1=1.59&r2=1.60
> )
>
>
> Fine, indeed, this prevents the crash described above. However, this
> seems to cause all these objects to leak. They cannot be collected. This
> is exactly what we are observing while profiling the application. The
> JNI global references prevents all the vtk Java wrapper objects from
> being collected and we quickly hit a out of memory error in the JNI layer.
>
> Questions:
> 1. Are they any modifications somewhere else in the VTK library in order
> to prevent the above leaking?
> 2. If not, do you have any suggestions/advices to guide us around the
> above problem by making a change in VTK itself or in our application?
> 2.1 Do you have any plan to fix the leakage problem or does it require a
> major change in VTK?
>
> We are actively working on this issue and are willing to contribute to
> the code base if we end-up with an elegant solution fixing both the
> random crashes and the memory leaking problem.
>
> Thanks,
> Francois
>
> --
> François Delisle
> Member of Research and Development
> Intelerad Medical Systems Incorporated
> 460 Ste-Catherine West, Suite 210
> Montreal, Quebec, Canada H3B 1A7
>
> Tel: 514.931.6222 x7534
> Fax: 514.931.4653
>
> francois.delisle at intelerad.com
> www.intelerad.com
>
> This email or any attachments may contain confidential or legally
> privileged information intended for the sole use of the addressees. Any
> use, redistribution, disclosure, or reproduction of this information,
> except as intended, is prohibited. If you received this email in error,
> please notify the sender and remove all copies of the message, including
> any attachments.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20070828/a6f33470/attachment.htm>