GNOME Bugzilla – Bug 697114
docs: advise not to use non-literal strings as qdata keys
Last modified: 2018-05-24 15:07:08 UTC
As is stated in bug #696757, the g_object_set_data() leaks memory for 'key' parameter when the parameters is an allocated string. There is no restriction on keys in documentation, thus this leak is unexpected. Adding such restriction is also unexpected, quite limiting. Relevant part of a valgrind log: 32,768 bytes in 1 blocks are definitely lost in loss record 4,033 of 4,039 at 0x4C28BED: malloc (vg_replace_malloc.c:263) by 0x8AF8D40: g_malloc (gmem.c:159) by 0x8B01AF5: g_quark_from_string (gquark.c:278) by 0x8673FFC: g_object_set_data (gobject.c:3318)
its not leaking, it is allocating a quark. To prevent that, you can call g_quark_from_static_string() beforehand.
It's not a static string, as I mentioned above, the 'key' is allocated and freed afterwards.
(In reply to comment #0) > Relevant part of a valgrind log: > > 32,768 bytes in 1 blocks are definitely lost in loss record 4,033 of 4,039 > at 0x4C28BED: malloc (vg_replace_malloc.c:263) > by 0x8AF8D40: g_malloc (gmem.c:159) > by 0x8B01AF5: g_quark_from_string (gquark.c:278) > by 0x8673FFC: g_object_set_data (gobject.c:3318) This leak is just for the lookup table. The actual memory used for the copy of the quark strings is likely to be much larger. That doesn't show up in valgrind memcheck because the memory is still reachable at program shutdown. I have not tested with valgrind massif (or plain old top); I suppose it would be visible there.
We've discussed this on IRC a bit. I think that we should block closing of this bug pending better documentation for g_object_set_data(). While many of us take it for granted that g_object_set_data() is implemented with GQuark, and that it should not be given dynamically generated strings potentially infinitely growing the GQuark array, in all fairness it's really not documented as such (and people without intimate knowledge of GObject internals will not realize this without better documentation).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/682.