On 02/08/2013 07:52 AM, John Ferlan wrote:
On 02/08/2013 09:26 AM, Michal Privoznik wrote:
> The virNetworkObjUpdateParseFile() function was not freeing the xml
> variable, leaving us with a memory leak.
> ---
> src/conf/network_conf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
> index c93916d..3604ff7 100644
> --- a/src/conf/network_conf.c
> +++ b/src/conf/network_conf.c
> @@ -1895,6 +1895,7 @@ virNetworkObjUpdateParseFile(const char *filename,
> ret = 0;
>
> cleanup:
> + xmlFreeDoc(xml);
> xmlXPathFreeContext(ctxt);
> return ret;
> }
>
ACK
Neither Coverity or Valgrind picked this up!
Hmm - on the Coverity side, that probably means doesn't know how to
model virXMLParse as an allocating function, or its was being filtered
out by hueristics. I wonder if Coverity is missing any other resource
leaks, or if we could add annotations to allocating functions to make
Coverity's job easier.
On the Valgrind side, that makes sense - valgrind only detects leaks
according to your actual execution usage; if you never pass libvirt
input that triggers this code path, valgrind can't complain about it.
I'm sure that it would be possible to write a test case that triggers
this code and would make valgrind complain; but don't know how easy or
hard it would be to get this extra coverage. Our tests definitely don't
have 100% code coverage yet, and probably never will (you hit a point of
diminishing returns, where it gets harder to trigger certain code paths).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org