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

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #11 from hendrich at informatik dot uni-hamburg dot de  
2006-06-13 10:15 -------
Subject: Re:  Massive memory leak in Graphics2D image operations

Hello Mark,

> Actually it wasn't the setCursor() call, it was just triggered by the
> HideCursorManager in combination with creating thumbnails which were using the
> GdkPixbugWriter which had some buggy gdk lock code. Hopefully all this has
> been fixed with the following patch:

cool. I wish I could debug like this...


The slight redraw offset in yesterday's cvs seems fixed today. I can start
niffler now with jamvm and cacao without deadlocks during program start.


Cacao always crashes after some time with an obscure error message, but
this happens with many Java programs, and is probably a bug in cacao itself:

   Cannot find Java function at 0x40be68dd
   cacao: codegen-common.c:547: codegen_findmethod: Assertion `0' failed.

   (I tried to report that bug, but their bugzilla registration doesn't work).


Jamvm works better, but memory usage is still rather high, and it still 
crashes when I try to load one particular image (a b&w scan of "Mambo No.5" 
with 2481x3408x1 pixels). I ran gdb on it with -Xmx200m specified, and I 
got the following result:

GLib-ERROR **: gmem.c:141: failed to allocate 139253568 bytes
aborting...
java.lang.InternalError: GLib: gmem.c:141: failed to allocate 139253568 bytes
   at gnu.java.awt.peer.gtk.CairoSurface.create(Native Method)
   at gnu.java.awt.peer.gtk.CairoSurface.<init>(CairoSurface.java:179)
   at
gnu.java.awt.peer.gtk.CairoSurface.getBufferedImage(CairoSurface.java:248)
   at gnu.java.awt.peer.gtk.GtkToolkit.createImage(GtkToolkit.java:210)
   at java.awt.Toolkit.createImage(Toolkit.java:641)
   at niffler.ImageUtils.loadImageViaToolkit(ImageUtils.java:200)
   at niffler.Niffler.loadImage(Niffler.java:1433)
   at niffler.Niffler.doLoadAndShowImage(Niffler.java:1600)

(gdb) where
#0  0x400da691 in kill () from /lib/libc.so.6
#1  0x40069511 in pthread_kill () from /lib/libpthread.so.0
#2  0x4006983b in raise () from /lib/libpthread.so.0
#3  0x400da424 in raise () from /lib/libc.so.6
#4  0x400dba50 in abort () from /lib/libc.so.6
#5  0x4d7b248a in IA__g_logv (log_domain=Variable "log_domain" is not
available.
) at gmessages.c:497
#6  0x4d7b24c9 in IA__g_log (log_domain=0x0, log_level=0, format=0x0)
    at gmessages.c:517
#7  0x4d7af7f0 in IA__g_malloc (n_bytes=139253568) at gmem.c:141
#8  0x4d25a7bb in Java_gnu_java_awt_peer_gtk_CairoSurface_create (
    env=0x806201c, obj=0x41f01140, width=2481, height=3508, stride=9924)
    at gnu_java_awt_peer_gtk_CairoSurface.c:62
#9  0x0805ecd5 in callJNIMethod (env=0x806201c, class=0x0, 
    sig=0x80753e0 "(III)V", ret_type=0, ostack=0x8255200, 
    f=0x4d25a770 "U\211å\203ì8\213E\b\211uø\211]ôèQÿÿÿ\201Ã0<\002", args=4)
    at dll_md.c:66
#10 0x0804f7a1 in callJNIWrapper (class=0x0, mb=0x84703e0, ostack=0x0)
    at dll.c:322
#11 0x08052847 in executeJava () at interp.c:2229
#12 0x08050447 in executeMethodVaList (ob=Variable "ob" is not available.
) at execute.c:91
#13 0x080504e9 in executeMethodArgs (ob=0x0, class=0x0, mb=0x0) at execute.c:63
#14 0x0805c441 in threadStart (arg=0x820a600) at thread.c:263
#15 0x40066c60 in pthread_start_thread () from /lib/libpthread.so.0


I would expect about 2481x3408x4 bytes, or 33,820.992 bytes for that image,
but 139M correspond to about 16 bytes per pixel... perhaps an extra factor
of four forgotten somewhere? The stride looks ok, but CairoSurface wants
stride*height*4.

- Norman









-- 


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