On Thu, May 31, 2018 at 10:06:37 +0200, Michal Privoznik wrote:
On 05/30/2018 06:57 PM, Peter Krempa wrote:
On Wed, May 30, 2018 at 18:04:29 +0200, Michal Privoznik wrote:
While this leak happens in tests only, it is still worth fixing.
==12962== 2,035 (104 direct, 1,931 indirect) bytes in 1 blocks are definitely lost in loss record 325 of 331 ==12962== at 0x4C2CF26: calloc (vg_replace_malloc.c:711) ==12962== by 0x5D285D5: virAlloc (viralloc.c:144) ==12962== by 0x5E823EB: virCPUGetHost (cpu.c:411) ==12962== by 0x56DE953: virQEMUCapsInitHostCPUModel (qemu_capabilities.c:2874) ==12962== by 0x56E062F: virQEMUCapsLoadCache (qemu_capabilities.c:3435) ==12962== by 0x13802F: qemuTestParseCapabilitiesArch (testutilsqemu.c:500) ==12962== by 0x1371F0: mymain (qemuxml2argvtest.c:2871) ==12962== by 0x13AD0B: virTestMain (testutils.c:1120) ==12962== by 0x1372FD: main (qemuxml2argvtest.c:2883)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_capabilities.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index e2e76e4dd8..9ec9089d5b 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1857,6 +1857,10 @@ virQEMUCapsSetHostModel(virQEMUCapsPtr qemuCaps, { virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
+ virCPUDefFree(cpuData->reported); + virCPUDefFree(cpuData->migratable); + virCPUDefFree(cpuData->full);
This looks fishy. The test code always unrefs the qemuCaps object, so there should be no leak. Could you please elaborate on how this happens?
Thing is, qemuTestParseCapabilitiesArch() calls virQEMUCapsLoadCache() (which exists only for sake of tests) which does two things:
1) roughly in the middle it calls virQEMUCapsLoadHostCPUModelInfo() where cpuData is firstly allocated
virQEMUCapsLoadHostCPUModelInfo calls virQEMUCapsSetCPUModelInfo which sets cpuData->info
2) at the end it calls virQEMUCapsInitHostCPUModel() which overwrites whatever was loaded in 1).
while virQEMUCapsInitHostCPUModel fills cpuData->reported, cpuData->migratable, and cpuData->full using the data from cpuData->info. It must be something else which causes the leak. Jirka