GNOME Bugzilla – Bug 66199
Potential memory leak in gtk_init
Last modified: 2011-02-18 15:58:17 UTC
Purify reports potential memory leak from gtk_init() like below: PLK: 40 bytes potentially leaked at 0x96820 This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] standard_calloc [glibgmem.c:111] g_malloc0 [glibgmem.c:154] type_node_any_new_W [gobjectgtype.c:287] type_node_fundamental_new_W [gobjectgtype.c:389] g_type_init_with_debug_flags [gobjectgtype.c:2886] g_type_init [gobjectgtype.c:2942] gdk_init_check [gdkgdk.c:322] gtk_init_check [gtkgtkmain.c:467] gtk_init [gtkgtkmain.c:672] main [testtext.o]
The problem here is that the g_hash_table_insert (static_type_nodes_ht, GUINT_TO_POINTER (node->qname), (gpointer) type); At the end of type_node_any_new_W() is failing since node->qname is 0. If this node doesn't need to be accessed anywhwere we could either just stick a pointer to the node into a static variable, or we could try to never create it or free it.
(Previous explanation was bogus, don't know what is going on)
Tim points out that what is probably going on here is that GLib does hacks where it doesn't keep a pointer to the _beginning_ of the GTypeNode How do we get purify to figure this out so people can run purify on GLib programs do we have to hack around this in some fashion? (I guess --enable-gc-friedly could cause us to keep another array around to the beginning of the fundamental types.)
Created attachment 6557 [details] purify output of possible memory leak in GtypeNode
Attached is a new purify report about this PLK error which I got with testgtk program in the gtk+ package. I ran it and just immediately hit 'close' button. It seems that g_type_init_with_debug_flags has created some GTypeNode objects whose pointers are not kept.
We think the problem is that GLib doesn't keep a pointer to the beginning of the allocated block for fundamental types. (It keeps a pointer to the GTypeNode, but allocates a larger block, and subtracts to get the pointer to the extended information.)' Does this make sense that it would confuse purify?
valgrind reports the same - potentially leaked memory, meaning that there is still a pointer to the middle of the block, just not to the beginning. If this is intended (as you seem to imply), I think we can close this.
IMO, GLib should take the hit and keep pointers to the start of the block as well to avoid problems for people using memory leak detection tools; Tim disagrees...