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