[Bug awt/27917] Massive memory leak in Graphics2D image operations

[mark at gcc dot gnu dot org]

------- Comment #4 from mark at gcc dot gnu dot org  2006-06-06 22:51 -------
(In reply to comment #3)
> with your patch in, garbage-collection seems to (partially) work for images
> again. I tried running the niffler slide-show at the default speed for about 
> 40
> images, and 'top' reported about 300M Virt and 200M RSS, periodically reduced
> to roughly 150M Virt after garbage-collection. Much better than without your
> patch! 

Thanks for testing. This part is good news.

> I then reduced the slide-show interval to about 0.5 seconds, which makes jamvm
> load the images about as fast as it can. Memory size quickly reached about
> 700+M Virt and 500M RSS, at which point my Linux crashed. This is only the
> second kernel crash that I remember (and the kernel has now equaled WinXP in
> this regard, too, after 3+ years of daily usage. Perhaps I should really
> upgrade the main memory, after all :-)).

Kernel crashes should not happen, even if our code is extremely buggy :{
But could you tell a bit more about your setup?
How many images, what kind of images, how big are they?
Do you generate thumbnails?
After how many images in the slideshow does the program become unusable?
Does the same thing happen if you just choose next by hand?
And how exactly do you start jamvm, any other arguments besides -Xmx300M?

> Note that I specified a -mx300M flag to jamvm, so that jamvm shouldn't have
> allocated more than 300MByte in the first place. Is the Gtk/Cairo memory
> allocated differently from the Java heap?!

Yes, the gtk+/cairo memory isn't allocated from the normal heap. And we have to
explicitly free anything we allocate, which apparently we don't do properly
everywhere.

BTW I am using valgrind --leak-check=full to find the leaks. valgrind gets a
little confused about the jamvm garbage collector, but for the gtk+/cairo jni
peers code it seems pretty accurate.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27917