libplist valgrind fixes
First patch fixes invalid read from valgrind
Second patch fixes memory leaks
-
Martin S.- 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().
-
teufHere 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.
-
teuf
Sorry for the spam, I really meant this patch :)
-
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.