GNOME Bugzilla – Bug 303675
memory management of GtkTreeModel unclear
Last modified: 2012-08-26 10:07:23 UTC
Version details: 2.6.8 Distribution/Version: debian sid I noticed a line in the documentation of gtk_tree_model_get(): "If appropriate, the returned values have to be freed or unreferenced." however, I could not find when it is appropriate to free the return values. After consulting the gtk-app-devel-list I came in contact with people that experienced the same problems and found out using a memory leak checker. That is certainly not what every gtk-app developer should do, so I guess we should improve the docs on this. My guess at this moment is that: - strings are copied in the tree model, so when setting the string you can use the string you used to set it, and when receiving a string from the model this is another copy which should be freed. -objects have their reference count incremented, so when setting an object the model holds it's own reference, and when getting an object you should decrement the reference count after you are finished not sure if there are more of these situations. I'm willing to write the documentation for this, but I'm not sure if my knowledge is complete..
Basically, you need to look at how the type system handles each type. For the fundamental types, look at glib/gobject/gvaluetypes.c and grep for "value_copy". For GObjects, grep for "value_copy" in gobject.c and you'll see that GObjects get ref()ed. It would be great to have documentation about this.
SOMEWHERE in the documentation, it mentions strings and objects... I think it even glances over pointers. Maybe amongst the GType docs... How about, where your documentation says, "the return value will need to be _free'd_and_unrefed_.", simply make "free'd and unrefed" a hyperlink back to a brief discussion on unref'ing GObjects, free'ing non-const strings, etc. And probably mention GBoxed's in there too... The same would go for return values; if it returns a non-const string, add "(_free_ when done)" to the end, with "free" hyperlinked back to that page also. And if you can't get inter-component hyperlinks going, then just throw in a paragraph or two near the front, and link to there (it can always reference the Glib documentation for further reference).
This bug seems to be fixed by this commit, which added more info about memory management: http://git.gnome.org/browse/gtk+/commit/gtk/gtktreemodel.c?id=2a12f74c8e8334d7b1f7629b99fd3e23f0f8a3af
agreed.