[vtkusers] VTK/Java crashes -- WeakGlobalRef or garbage collection problem...solution?

[Luke Dodd]

I have put together a very rough version of the global lock idea
suggested by Jeff Baumes. I have included the patch in this mail. It
applies to CVS head, although I imagine with no or little tweaking it
could apply to the latest release too. (I hope it's OK to include a
file with the mailing list... it's pretty small)

The good news is that it seems to work, at least for me! I have not
actually managed to get my program to crash (even when prompting
garbage collection) yet... I'm pretty excited about this!

This is a _very_ rough patch, I put it together very quickly and I'm
sure there are methods that it probably does not even apply the lock
to, but for the majority it does (in particular the Delete method,
which since I have made vtkDeleted volatile makes the finalizer
"thread safe"). It is good enough to eliminate crashes for me, so far
:)

Another thing to not is that I have included the following patch in
too since I was playing with the deleted method anyway.
http://public.kitware.com/Bug/view.php?id=8942

Nathan: Could you explain your suggestion with a
"vtkJavaGarbageCollectionContext" a little more? Do you think it is
worth doing if the global lock works?

I'd love for other people to take a look at this patch and see if it
works and let me know. Perhaps even if it does work the performance
hit is too hard (although I have not noticed much difference). If
people like it I'll make improvements and see where we go from there.

    Luke

2009/12/17 Nathan P Sharp <vtkusers at nps.parcellsharp.net>:
> Luke Dodd escribió:
>> I'm going to take a look at the global mutex lock and see if it fixes
>> the issues I have been having with  the Java wrappers. If it turns out
>> to be too slow/does not work I'll go for manual Delete calls. I'll
>> have a look at this today/tomorrow and report back!
>>
>> Luke
>>
>>
> Luke,
>  Thanks to everyone for helping with this.  This is a very difficult
> problem to work on because when it fails, often the crash is long after
> the mistake (which wrote to a bad pointer).
>   I personally would be in favor of manually deleting objects because
> we are also having problems with major memory and GDI handle leaks.
> For us VTK is a small piece in a larger application that might be short
> lived compared to the process life-span, so static options like
> DeleteAll() aren't feasible and I never trust the garbage collector.
>  As a suggestion, what if you could optionally pass in a
> "vtkJavaGarbageCollectionContext" to any object construction.  It would
> be an unsynchronized map of actual references that would keep my objects
> from self-deleting until I know I'm done with the particular chart and
> it would allow me to group vtk objects together for cleanup at an
> appropriate time.  It could fall back on the vtkGlobalJavaHash (and weak
> refs) if not supplied for backwards compatibility.  A cmake option to
> turn off backwards compatibility would be very desirable.
>
>  Nathan
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 5566 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20091217/fa600600/attachment.obj>