Libiphone libiphone

Comments and changes to this ticket

• 

  Martin S. November 18th, 2009 @ 10:02 PM

  • State changed from “new” to “open”
  • Assigned user set to “Jonathan Beck”

  I remember that the changes in patch #2 actually had some complications in the history.

  Most of the time one creates a couple of plists and "glues" them together. Thus one has references to a couple of subnodes and perhaps a root level node.

  Now, the usual coder would free the individual subnodes created earlier and the root node.

  However, now imagiine what happens if a subnode is free'd.

  I think the issue in the early days of libplist was that in this case the subnode was not unlinked and thus g_node_destroy() on any parent node crashed as it still attempted to reference the already free'd but still linked subnode.

  Maybe this was fixed within glib or the issue has appeared in a different context but I clearly remember there have been some crasher and valgrind fun especially with g_node_unlink() and g_node_destroy().

• You flagged this item as spam.
  

  teuf November 18th, 2009 @ 11:55 PM

  Here is an alternate patch that keeps the g_node_unlink. It won't solve the issue you describe since if one keep pointers "inside" the tree and frees the memory associated with these pointers, the toplevel node pointed by each of these pointers might be freed several times depending on the order in which you free the nodes. Imo the case you describe falls in the "if that hurts, don't do that" category.

  • 0001-don-t-leak-gnodes-in-plist_free.patch 1 KB

• You flagged this item as spam.
  

  teuf November 18th, 2009 @ 11:56 PM

  Sorry for the spam, I really meant this patch :)

  • 0001-don-t-leak-gnodes-in-plist_free.patch 1.2 KB
• 

  Jonathan Beck November 19th, 2009 @ 05:17 PM

  • Tag cleared.
  • State changed from “open” to “resolved”

  Applied, thanks