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).
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 !
regards,
/John, who have one more newbie haskell question for the cafe or
or beginners MLs …
# Glib memory monitor for poor programmers.
# Invoke it this way:
# bash $ gdb -x glib.gdb ./yourProgram
set pagination off
set $RED="[31m"
set $GREEN="[32m"
set $RESET="[0m"
# We wait in main for glib libraries to be loaded
break main
run
# When in main, define our breakpoints ...
break g_object_ref
commands
silent
set $myType=((GTypeClass*)((GTypeInstance*)_object)->g_class)->g_type
set $myName=(gchar*)g_type_name($myType)
set $myCount=((GObject*)(_object))->ref_count + 1
printf "%s",$GREEN
printf "[%d] +++ %s at 0x%x\n",$myCount,$myName,_object
printf "%s",$RESET
continue
end
# When in main, define our breakpoints ...
break g_object_unref
commands
silent
set $myType=((GTypeClass*)((GTypeInstance*)_object)->g_class)->g_type
set $myName=(gchar*)g_type_name($myType)
set $myCount=((GObject*)(_object))->ref_count - 1
printf "%s",$RED
printf "[%d] --- %s at 0x%x[0m\n",$myCount,$myName,_object
printf "%s",$RESET
continue
end
# When in main, define our breakpoints ... and RESUME !
continue
quit
# vim:filetype=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
