Re: ChamplainMapSourceChain ref_sink in champlain_view_set_map_source

[Jiří Techet <techet gmail com>]

On Thu, Apr 22, 2010 at 04:38, Victor Godoy Poluceno
<victorpoluceno gmail com> wrote:
> Hi everyone,
>
> I'm porting the 'local-rendering.c' demo to python and I get the
> message below and some 'segfaults' when I set a
> 'ChamplainMapSourceChain' to the 'map-source' property in 'view':
>
> ** (launcher-gtk.py:1707): CRITICAL **:
> champlain_map_source_get_tile_size: assertion `CHAMPLAIN_IS_MAP_SOURCE
> (map_source)' failed
>
> After some investigation, I think that problem happens after the
> 'g_object_ref_sink(source)' in 'champlain_view_set_map_source', line
> 2476. So, I changed g_object_ref_sink to g_object_ref and my code
> works properly without any message.
>
> There are any reason to use g_object_ref_sink or why that happens? If
> someone can help me I will appreciate that. I'm using Ubuntu Lucid
> Beta 2.
>
> --
> Victor Godoy Poluceno
> _______________________________________________
> libchamplain-list mailing list
> libchamplain-list gnome org
> http://mail.gnome.org/mailman/listinfo/libchamplain-list
>

Hi,

the ref_sink() was introduced by

f254bb3ddb01f4a74f8b8edc67996cdd93b32e2f
52e76f7fc148a60ee2518bace128c64dad5e9800

and I followed this style too when doing some changes to libchamplain.
What I guess happens in your case is that you call something like
this:

foo = champlain_map_source_chain_new()
// add some map sources into it
champlain_view_set_map_source(foo)
g_object_unref(foo)

What's wrong is the last line - because map sources inherit from
GInitiallyUnowned now, when the objects are created, they have a
"floating reference" and when g_object_ref_sink(foo) is called, it
only clears the floating reference flag but does not increase the
reference count so calling g_object_unref(foo) above destroys the
object and champlain_view contains pointer to an invalid object. See
this

http://library.gnome.org/devel/gobject/unstable/gobject-The-Base-Object-Type.html#floating-ref

for more info.

This is an easy to overlook change in 0.5 with nasty consequences so
it would be good if all the binding maintainers checked their code if
it does the right thing (and go through the headers to see which
classes inherit from GInitiallyUnowned now).

(I could see that something like that happened also when I clicked the
map in your python bindings branch - may be related.)

Jiri