Kirill Batuzov writes:
> I tried running QEMU under Valgrind's Memcheck tool and managed to find
> some memory leaks. I only checked "definitely lost" reports. I ignored
> reports related to SDL/GTK because it is hard to tell if memory leak occurred
> in QEMU or in the library.
>
> All found er
On 18 April 2014 18:08, Kirill Batuzov wrote:
> And something like this happens every time qemu_allocate_irqs is called.
Which generally only happens in the board init stage, ie once.
So why care? Leaks are interesting if they happen in code that
could be called multiple times (eg for hotplugged
Note that generally these "leaks" are not really leaks, because we
set up the board and wire IRQs together once, and they remain
that way for the lifetime of QEMU and are freed automatically
when QEMU exits.
Unfortunately they are really leaks. As I said qemu_allocate_irqs
allocates two chunks
On 18 April 2014 14:41, Kirill Batuzov wrote:
> qemu_allocate_irqs:
> The most troublesome case. It will need its own patch series and I need
> some advices on how to deal with it.
I would suggest that we should deal with this by converting
from qemu_irq to a QOM property or link based inter
I tried running QEMU under Valgrind's Memcheck tool and managed to find
some memory leaks. I only checked "definitely lost" reports. I ignored
reports related to SDL/GTK because it is hard to tell if memory leak occurred
in QEMU or in the library.
All found errors followed one pattern:
1) Calle
