On Wed, Nov 30, 2011 at 06:26:18PM +0100, Christophe Fergeau wrote: > > + > > + if (!(old_node = gvir_config_xml_get_element(parent_node, child_name, > > NULL))) > > + return; > > + > > + /* FIXME: should we make sure there are no multiple occurrences > > + * of this node? > > + */ > > + xmlUnlinkNode(old_node); > > + xmlFreeNode(old_node); > > +} > > > I think we will get memory corruption if this API is combined with > _attach_child:
And I'm wrong since the whole point of the introduction of GVirConfigXmlDoc
is to avoid this kind of memory corruption. However, in the example below,
fs_node will have a reference to a GVirConfigXmlDoc which has no relation
with its GVirConfigObject::node pointer, and this pointer will be pointing
to already freed memory which is suboptimal.
>
> device_node = gvir_config_object_new("device");
> fs_node = gvir_config_object_new("fs");
> gvir_config_object_attach(device_node, fs_node);
> gvir_config_object_delete_child(device_node, "fs");
> g_object_unref(G_OBJECT(fs_node));
>
> The xmlNodePtr held by fs_node will be freed twice, once by _delete_child
> and when _finalize runs after the call to g_object_unref
>
> Having each GVirConfigObject keep a list of its GVirConfigObject children
> would make it possible to handle this case I think.
>
> I'm fine with getting this function in even if there are known issues with
> it.
Christophe
pgpcvmpOoD6nP.pgp
Description: PGP signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
