On Mon, Mar 17, 2014 at 09:56:45PM +0100, Christian Borntraeger wrote:
> Marcel,
>
> after
>
> commit 261747f176f6 (vl: Use MachineClass instead of global QEMUMachine list)
> valgrind complains about the following:
>
> ==54082== 57 bytes in 3 blocks are definitely lost in loss record 365 of 72
On 17/03/14 22:25, Peter Maydell wrote:
> On 17 March 2014 20:56, Christian Borntraeger wrote:
>> Turns out that valgrind is right. We simply forget the memory that
>> g_strconcat has allocated.
>> This fixes the small leak, but I have to cast away the constness of .name.
>> Any better ideas?
>
On Mon, 2014-03-17 at 22:29 +0100, Christian Borntraeger wrote:
> On 17/03/14 22:25, Peter Maydell wrote:
> > On 17 March 2014 20:56, Christian Borntraeger
> > wrote:
> >> Turns out that valgrind is right. We simply forget the memory that
> >> g_strconcat has allocated.
> >> This fixes the small
Am 17.03.2014 22:29, schrieb Christian Borntraeger:
> On 17/03/14 22:25, Peter Maydell wrote:
>> On 17 March 2014 20:56, Christian Borntraeger wrote:
>>> Turns out that valgrind is right. We simply forget the memory that
>>> g_strconcat has allocated.
>>> This fixes the small leak, but I have to
On 17 March 2014 20:56, Christian Borntraeger wrote:
> Turns out that valgrind is right. We simply forget the memory that
> g_strconcat has allocated.
> This fixes the small leak, but I have to cast away the constness of .name.
> Any better ideas?
It's how cpu_register() in target-arm/cpu.c does
Marcel,
after
commit 261747f176f6 (vl: Use MachineClass instead of global QEMUMachine list)
valgrind complains about the following:
==54082== 57 bytes in 3 blocks are definitely lost in loss record 365 of 729
==54082==at 0x4031AFE: malloc (vg_replace_malloc.c:292)
==54082==by 0x4145569
