[Discussion] Did you ever forget to un_ref any GObject?

[Sebastian Dröge]

On Di, 2015-01-06 at 18:10 -0800, hxpax wrote:
> That could be a big problem on some other platforms, more than just a
> segfault.

It could result in worse situations, yes.

> I wonder are there any conventions for unref?

The docs would tell you, they now have annotations on parameters and
return values hopefully everywhere. Like (transfer none), (transfer
full), (transfer container) and (transfer floating).

none: for return values you don't own it and must not unref it, for
parameters you still own it and must unref it

full: for return values you own it and must unref it, for parameters you
don't own it anymore and must get another reference with ref before
passing it to the function if you still need it afterwards

container: only used for containers, e.g. lists. Means the same as
transfer full for the actual container, but transfer none for the
elements of the container

floating: tricky one, check the documentation for floating references
first. It means for return values that you get a floating reference, for
parameters it means that it is transfer full for floating references and
transfer none for non-floating references.


General rule is that setter should be transfer none, getter transfer
full, adder (e.g. gst_bin_add()) transfer full or transfer floating.
Exception for getters (and things like gst_message_parse_*) are things
like GstStructure, GstMessage, etc where the return value is transfer
none and stays valid as long as you have a reference to its container.
Functions that take a const pointer or return one are by definition
transfer none.

Things that pass buffers/messages/events on to other pads/elements are
transfer full (e.g. gst_pad_push(), gst_element_post_message()), query
related things are transfer none. Reason is that you usually want to get
rid of the references of the former when passing it (also to keep
buffers writable downstream if possible), while for queries you still
want to own the reference (how would you otherwise get the query result
later?).

Unfortunately there are a few inconsistencies and exceptions to these
rules.

Hope this helps!

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150109/f0dcf9a7/attachment.sig>