Re: pixbuf leakage

"Walter C. Pelissero" <[email protected]> writes:

> I believe your example was missing an unref:
> 
>       fclose (stream);
>       gdk_pixbuf_loader_close (loader, NULL);
> +     g_object_unref(loader);
>     }
> }
> 
> With that in, no memory leak is reported by the profiling functions,
> although the process does get quite big nevertheless.

Yes, you're right. Forgetting those unrefs is easy when one is used to
GC-ing. 

But it suddenly occurred to me why this code is leaking memory. The
signal handler closures keep references to the loader object, which
prevents the ref count from reaching zero and thus freeing the object. I
don't think it is possibly avoid this, but there are two ways to work
around the problem. One is to disconnect the signal handlers when loader
is not used any more. The other is to give the loader object as the
first argument to the callback functions with the object keyword
argument to signal-connect (this requires the latest code from CVS due
to a couple of bugs in earlier code).

-- 
Espen

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone