Am 18.08.2012 22:51, schrieb Stefan Weil:
valgrind report:
==24534== 232 bytes in 2 blocks are definitely lost in loss record 1,245 of
1,601
==24534== at 0x4824F20: malloc (vg_replace_malloc.c:236)
==24534== by 0x293C88: malloc_and_trace (vl.c:2281)
==24534== by 0x489AD99: ??? (in /lib/libglib-2.0.so.0.2400.1)
==24534== by 0x489B23B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1)
==24534== by 0x2B4EFC: opts_visitor_new (opts-visitor.c:376)
==24534== by 0x29DEA5: net_client_init (net.c:708)
==24534== by 0x29E6C7: net_init_client (net.c:966)
==24534== by 0x2C2179: qemu_opts_foreach (qemu-option.c:1114)
==24534== by 0x29E85B: net_init_clients (net.c:1008)
==24534== by 0x296F40: main (vl.c:3463)
valgrind reports a lot more memory leaks which are related to
function qemu_allocate_irqs. In many cases, its return value
should be free'd. g_malloc / g_free can be avoided by adding
a new function
void qemu_init_irqs(qemu_irq_handler handler, void *opaque,
qemu_irq *irqs, int n);
If this is ok, I'll send patches which add and use the new
function instead of qemu_allocate_irqs, too.
Regards,
Stefan Weil
