------- Comment #6 from hendrich at informatik dot uni-hamburg dot de 2006-10-23 17:24 ------- (In reply to comment #5) > No, nothing since the 20'th. I'm assuming these images should not be in > memory > concurrently (slideshow loads one, then moves on to the next, and the original > image *should* be freed) - so a memory leak somewhere?
Yes. Either a leak or memory corruption, probably in the JNI/GTK parts. (A while ago, after I last reported similar OOME problems, Mark fixed several leaks in the GTK code. But I have no idea whether and where current cvs might trigger those anew.) The image viewer really only keeps one reference to the current image, and a temporary reference to the image it is next loading. I also had the "thumbnails panel" disabled for these tests; but the slideshow wait interval was so low that the JVM was continually loading new images. (When thumbnails generation and display is on, niffler also keeps a cache of the thumbnail images. But the thumbnails are really small, and the cache is cleared when memory runs low.) With cp cvs 2006.10.20, slideshows usually survive at least 200 images (jamvm with -Xmx300m), but the VM seems to get very unstable beyond that. Most often, the VM just crashes with a segfault, but here is one of the OOME stacktraces I got: java.lang.OutOfMemoryError at gnu.java.awt.peer.gtk.GtkImage.getPixels(Native Method) at gnu.java.awt.peer.gtk.CairoSurface.<init>(CairoSurface.java:181) at gnu.java.awt.peer.gtk.CairoSurface.getBufferedImage(CairoSurface.java:261) at gnu.java.awt.peer.gtk.GtkToolkit.createImage(GtkToolkit.java:255) at java.awt.Toolkit.createImage(Toolkit.java:661) at niffler.ImageUtils.loadImageViaToolkit(ImageUtils.java:253) at niffler.ImageUtils.loadImageViaToolkit(ImageUtils.java:211) at niffler.Niffler.loadImage(Niffler.java:1622) ... at niffler.SlideshowManager.run(SlideshowManager.java:82) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29420 _______________________________________________ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath