Good evening ! Following my previous thread on xfconf and GObject management, I've looked at the Pixbuf memory leak (bug #1202).
(...some darcs, ghc-pkg unregister and cabal install later ...) Simply replacing constructNewGObject in the pixbuf functions (pixbufNew, pixbufScaleSimple, ...) by a new "wrapNewGObject" which does NOT ref or refSink the object seems to solve the memory leak. But, it only works with the GHC option "-threaded". If I compile with lightweight/buildin GHC threading system, I still have the *same* memory issue. Attached is a short graph of the Resident Set Size memory consumption for a test program (pixbufNew & loop on pixbufScaleSimple) showing 4 results, with or without the "-threaded" compile option and with `constructNewGObject` (aka trunk) or `wrapNewGObject` (aka wrap) So, how should I understand the situation ? Is this a known bug in my GHC (version 6.12.1) or something else ? I thought that compiling with or without the '-threaded' option should not alter the result of the program. I prefer to ask for advice now before replacing tens of `constructNewGObject` by a new buggy function. regards, /John
wrapNewGObject_test.patch.gz
Description: GNU Zip compressed data
<<attachment: wrapNewGObject.png>>
pgpQxqPINr5w2.pgp
Description: PGP signature
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb
_______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
