Le 11/05/2021 à 07:38, Markus Armbruster a écrit :
> Stefano Garzarella writes:
>
>> Ping :-)
>>
>> Should I resend for 6.1?
>
> I'm cc'ing qemu-trivial.
>
> For good measure:
> Reviewed-by: Markus Armbruster
>
>
Applied to my trivial-patches branch.
Thanks,
Laurent
Stefano Garzarella writes:
> Ping :-)
>
> Should I resend for 6.1?
I'm cc'ing qemu-trivial.
For good measure:
Reviewed-by: Markus Armbruster
Ping :-)
Should I resend for 6.1?
Thanks
Stefano
On Mon, Apr 12, 2021 at 07:02:55PM +0200, Stefano Garzarella wrote:
get_relocated_path() allocates a GString object and returns the
character data (C string) to the caller without freeing the memory
allocated for that object as reported by valgr
On Mon, Apr 12, 2021 at 9:06 PM Stefano Garzarella
wrote:
> get_relocated_path() allocates a GString object and returns the
> character data (C string) to the caller without freeing the memory
> allocated for that object as reported by valgrind:
>
> 24 bytes in 1 blocks are definitely lost in l
On 4/13/21 1:47 PM, Stefano Garzarella wrote:
> On Tue, Apr 13, 2021 at 12:59:36PM +0200, Philippe Mathieu-Daudé wrote:
>> Is this fix aiming at 6.0 release?
>
> The leak is minimal, but the fix is very simple.
> So, I think it can go if someone has a pull request to send with other
> patches, but
On Tue, Apr 13, 2021 at 12:59:36PM +0200, Philippe Mathieu-Daudé wrote:
Is this fix aiming at 6.0 release?
The leak is minimal, but the fix is very simple.
So, I think it can go if someone has a pull request to send with other
patches, but I'm not sure with which tree.
Thanks,
Stefano
On
Is this fix aiming at 6.0 release?
On 4/12/21 7:02 PM, Stefano Garzarella wrote:
> get_relocated_path() allocates a GString object and returns the
> character data (C string) to the caller without freeing the memory
> allocated for that object as reported by valgrind:
>
> 24 bytes in 1 blocks a
get_relocated_path() allocates a GString object and returns the
character data (C string) to the caller without freeing the memory
allocated for that object as reported by valgrind:
24 bytes in 1 blocks are definitely lost in loss record 2,805 of 6,532
at 0x4839809: malloc (vg_replace_mallo
