Hi John, On Oct 3, 2010, at 22:42, John Obbele wrote:
> Hi again ! > > To conclude my long list of posts, here comes what I've > understood of GObjects construction and memory management: > >>> [...] from the official C API documentation: >>> http://www.xfce.org/documentation/4.6/api/xfconf/xfconf-xfconf-channel.html#xfconf-channel-get >>> >>> One can read that xfconf_channel_get() returns a XfconfChannel* >>> object which is owned by the daemon and should *NOT* be >>> g_object_unref(), whereas xfconf_channel_new*() return normal >>> GObjects. >>> >> [...] >> >> Have you checked the constructGObject function? It might be the >> correct way to handle channel_get if this function creates a >> floating reference only. The docs of channel_get are very terse, it >> might help to look at the source code. > > > First, I must say that I have successfully used GDB to monitor > and debug my GOBjects. I am using conditional breakpoints and a > file containing the GDB commands to automate the task. For > curious people, the file is attached to this message. It's an old > trick well known on the glib/gtk+2 development mailing lists and > wikis and I'm very happy to have learned these gdb (basic?) > features. > > > Surprisingly, gdb somehow works on Haskell FFI binaries. Well, > only partially on their pseudo C stack, but it was more than > enough in my case :) > > > So my solution for the XfconfChannel memory management is: > > 1) xfconf_channel_get returns a singleton object owned by the xfconf > daemon. You do not have to object_ref or unref it. Yet gtk2hs > forces you to bind a "unref" finalizer to it. > > One practical solution is to use constructNewGObject, which > calls objectRefSink and artificially increments the ref_count. > When Haskell clean its memory, it finalizes the object with > g_object_unref. The ref_count decreases and goes back to its > normal value. > > It just works fine™, although I still do not understand how > g_object_object_ref_sink performs internally ^^ > > Optimally, I would wish to provide a dummy memory finalizer to > the gtk2hs GObject implementation but it seems this can't be > easily done (for good reasons I assume). > The good reason is that XfconfChannel may cease to exist before the Haskell object goes out of scope (well, at least in principle this is a possibility). If you don't use constructNewGObject, then Haskell land may refer to a destroyed C structure. > 2) xfconf_channel_new returns a newly created clone. You need to > call object_unref to free it but neither object_ref nor > object_ref_sink. Problem: makeNewGObject calls the former and > constructNewGObject the latter. > > Simple solution : call directly the C functions like this: > > channelNew :: String -> IO XfconfChannel > channelNew name = > withUTFString name $ \cname -> do > objPtr <- {#call xfconf_channel_new #} cname > obj <- newForeignPtr objectUnref objPtr > return $! XfconfChannel obj > > > I've quickly tested the other parts of gtk2hs I am using (mainly > GValues) and all seems fine memory wise, so once again, many > thanks for your hard work and your help ! > I consider this behaviour as broken. I think object_ref_sink should do the right job for exactly this problem. If it doesn't then our other code might be broken (or XFconf is simply not adapted to the new sink/ ref mechanism, although I thought it should be backwards compatible). Cheers, Axel > regards, > /John, who have one more newbie haskell question for the cafe or > or beginners MLs … > < > glib > .gdb > > > ------------------------------------------------------------------------------ > Virtualization is moving to the mainstream and overtaking non- > virtualized > environment for deploying applications. Does it make network security > easier or more difficult to achieve? Read this whitepaper to > separate the > two and get a better understanding. > http://p.sf.net/sfu/hp-phase2-d2d_______________________________________________ > Gtk2hs-devel mailing list > Gtk2hs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
