On Friday, 21 October 2016 16:20:30 CEST Eric Blake wrote:
> On 10/18/2016 06:22 AM, Pino Toscano wrote:
> > On Tuesday, 18 October 2016 06:13:30 CEST Eric Blake wrote:
> >> On 10/18/2016 04:17 AM, Pino Toscano wrote:
> >>> qmp_output_start_struct() and qmp_output_start_list() create a new
> >>> QO
On 10/18/2016 06:22 AM, Pino Toscano wrote:
> On Tuesday, 18 October 2016 06:13:30 CEST Eric Blake wrote:
>> On 10/18/2016 04:17 AM, Pino Toscano wrote:
>>> qmp_output_start_struct() and qmp_output_start_list() create a new
>>> QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor
On Tuesday, 18 October 2016 06:13:30 CEST Eric Blake wrote:
> On 10/18/2016 04:17 AM, Pino Toscano wrote:
> > qmp_output_start_struct() and qmp_output_start_list() create a new
> > QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
> > where it is saved as 'value'. When freei
On 10/18/2016 06:13 AM, Eric Blake wrote:
> On 10/18/2016 04:17 AM, Pino Toscano wrote:
>> qmp_output_start_struct() and qmp_output_start_list() create a new
>> QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
>> where it is saved as 'value'. When freeing the iterator in
>>
On 10/18/2016 04:17 AM, Pino Toscano wrote:
> qmp_output_start_struct() and qmp_output_start_list() create a new
> QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
> where it is saved as 'value'. When freeing the iterator in
> qmp_output_free(), these values are never freed
On Tuesday, 18 October 2016 11:44:26 CEST Kevin Wolf wrote:
> Am 18.10.2016 um 11:18 hat Pino Toscano geschrieben:
> > The 'obj' result of the visitor was not properly freed, like done in
> > other places doing a similar job.
> > ---
> > block/qapi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
Am 18.10.2016 um 11:18 hat Pino Toscano geschrieben:
> The 'obj' result of the visitor was not properly freed, like done in
> other places doing a similar job.
> ---
> block/qapi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/block/qapi.c b/block/qapi.c
> index 6f947e3..50d3090 100644
qmp_output_start_struct() and qmp_output_start_list() create a new
QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
where it is saved as 'value'. When freeing the iterator in
qmp_output_free(), these values are never freed properly.
The simple solution is to qobject_decref
The 'obj' result of the visitor was not properly freed, like done in
other places doing a similar job.
---
block/qapi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/qapi.c b/block/qapi.c
index 6f947e3..50d3090 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -698,6 +698,7 @@ void bdrv_
On Sun, 19 Aug 2012 12:12:29 +0200
Laszlo Ersek wrote:
> On 08/18/12 22:51, Stefan Weil wrote:
> > 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 0
On 18 August 2012 22:01, Stefan Weil wrote:
> 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 handle
On 08/18/12 23:06, Michael Tokarev wrote:
> On 19.08.2012 00:51, Stefan Weil wrote:
>
>> +++ b/qapi/opts-visitor.c
>> @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov)
>
>> g_hash_table_destroy(ov->unprocessed_opts);
>> }
>> g_free(ov->fake_id_opt);
>> -memset(ov, '
On 08/18/12 22:51, Stefan Weil wrote:
> 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: ???
On 19.08.2012 00:51, Stefan Weil wrote:
> +++ b/qapi/opts-visitor.c
> @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov)
> g_hash_table_destroy(ov->unprocessed_opts);
> }
> g_free(ov->fake_id_opt);
> -memset(ov, '\0', sizeof *ov);
> +g_free(ov);
Shouldn't the fu
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
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 0x
16 matches
Mail list logo