On Wed, Jan 27, 2010 at 11:17:32AM +0100, Jim Meyering wrote: > Daniel P. Berrange wrote: > > On Wed, Jan 27, 2010 at 10:38:55AM +0100, Jim Meyering wrote: > >> Actually, the preceding patch fixed only the one leak that had been > >> introduced in the last month or so. Looking at the many other functions > >> that do the same sort of thing (call qemuMonitorJSONMakeCommand, and > >> later virJSONValueFree), I saw that they all had exactly the same leak. > >> So this amended patch fixes all of them: > >> > >> >From 28f820354dcae9950cad042ea78a893fd9475830 Mon Sep 17 00:00:00 2001 > >> From: Jim Meyering <meyering@xxxxxxxxxx> > >> Date: Wed, 27 Jan 2010 09:58:12 +0100 > >> Subject: [PATCH] qemu_monitor_json.c: avoid many unconditional leaks > > > > The real bug is the virJSONValueFree() itself which is missing > > the final VIR_FREE(value) call. By doing the free in the caller, we > > still leak data for compound array/hash values. > > Putting the VIR_FREE in virJSONValueFree was my first reflex, too, > but since coverity detected no leak for the adjacent > "virJSONValueFree(reply);" use, I assumed that doing so would > cause a problem: > > virJSONValueFree(cmd); > VIR_FREE(cmd); > virJSONValueFree(reply); I think coverity must be confused then :-) The virJSONValueFree() method is definitely intended to free any memory allocated during one of the virJSONValueNewXXXX() methods. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list