The cpuModels member of _virQEMUCapsAccel struct is not a
virObject but regular struct with a free function defined:
qemuMonitorCPUDefsFree(). Use that when clearing parent structure
instead of virObjectUnref() to avoid a memleak:
==212322== 57,275 (48 direct, 57,227 indirect) bytes in 3 blocks are definitely lost in loss record 623 of 627
==212322== at 0x4838B86: calloc (vg_replace_malloc.c:762)
==212322== by 0x554A158: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.6)
==212322== by 0x17B14BF5: qemuMonitorCPUDefsNew (qemu_monitor.c:3587)
==212322== by 0x17B27BA7: qemuMonitorJSONGetCPUDefinitions (qemu_monitor_json.c:5616)
==212322== by 0x17B14B0B: qemuMonitorGetCPUDefinitions (qemu_monitor.c:3559)
==212322== by 0x17A6AFBB: virQEMUCapsFetchCPUDefinitions (qemu_capabilities.c:2571)
==212322== by 0x17A6B2CC: virQEMUCapsProbeQMPCPUDefinitions (qemu_capabilities.c:2629)
==212322== by 0x17A70C00: virQEMUCapsInitQMPMonitorTCG (qemu_capabilities.c:4769)
==212322== by 0x17A70DDF: virQEMUCapsInitQMPSingle (qemu_capabilities.c:4820)
==212322== by 0x17A70E99: virQEMUCapsInitQMP (qemu_capabilities.c:4848)
==212322== by 0x17A71044: virQEMUCapsNewForBinaryInternal (qemu_capabilities.c:4891)
==212322== by 0x17A7119C: virQEMUCapsNewData (qemu_capabilities.c:4923)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
src/qemu/qemu_capabilities.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index e5f19ddcaa..f65af5c228 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1798,7 +1798,7 @@ virQEMUCapsAccelClear(virQEMUCapsAccelPtr caps)
VIR_FREE(caps->machineTypes);
virQEMUCapsHostCPUDataClear(&caps->hostCPU);
- virObjectUnref(caps->cpuModels);
+ qemuMonitorCPUDefsFree(caps->cpuModels);
}
--
2.23.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Nov 25, 2019 at 16:41:33 +0100, Michal Privoznik wrote: > The cpuModels member of _virQEMUCapsAccel struct is not a > virObject but regular struct with a free function defined: > qemuMonitorCPUDefsFree(). Use that when clearing parent structure > instead of virObjectUnref() to avoid a memleak: > > ==212322== 57,275 (48 direct, 57,227 indirect) bytes in 3 blocks are definitely lost in loss record 623 of 627 > ==212322== at 0x4838B86: calloc (vg_replace_malloc.c:762) > ==212322== by 0x554A158: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.6) > ==212322== by 0x17B14BF5: qemuMonitorCPUDefsNew (qemu_monitor.c:3587) > ==212322== by 0x17B27BA7: qemuMonitorJSONGetCPUDefinitions (qemu_monitor_json.c:5616) > ==212322== by 0x17B14B0B: qemuMonitorGetCPUDefinitions (qemu_monitor.c:3559) > ==212322== by 0x17A6AFBB: virQEMUCapsFetchCPUDefinitions (qemu_capabilities.c:2571) > ==212322== by 0x17A6B2CC: virQEMUCapsProbeQMPCPUDefinitions (qemu_capabilities.c:2629) > ==212322== by 0x17A70C00: virQEMUCapsInitQMPMonitorTCG (qemu_capabilities.c:4769) > ==212322== by 0x17A70DDF: virQEMUCapsInitQMPSingle (qemu_capabilities.c:4820) > ==212322== by 0x17A70E99: virQEMUCapsInitQMP (qemu_capabilities.c:4848) > ==212322== by 0x17A71044: virQEMUCapsNewForBinaryInternal (qemu_capabilities.c:4891) > ==212322== by 0x17A7119C: virQEMUCapsNewData (qemu_capabilities.c:4923) > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > --- > src/qemu/qemu_capabilities.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index e5f19ddcaa..f65af5c228 100644 > --- a/src/qemu/qemu_capabilities.c > +++ b/src/qemu/qemu_capabilities.c > @@ -1798,7 +1798,7 @@ virQEMUCapsAccelClear(virQEMUCapsAccelPtr caps) > VIR_FREE(caps->machineTypes); > > virQEMUCapsHostCPUDataClear(&caps->hostCPU); > - virObjectUnref(caps->cpuModels); > + qemuMonitorCPUDefsFree(caps->cpuModels); > } Oops, introduced by v5.9.0-318-gbc0b22884a which switched cpuModels from virDomainCapsCPUModelsPtr (virObject) to qemuMonitorCPUDefsPtr. Unfortunately, virObjectUnref takes void * so the compiler could not help here. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.