qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Fabiano Rosas <farosas@suse.de>, qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] tests/qtest: Plug memory leaks in qtest_get_machines
Date: Tue, 24 Jan 2023 08:25:04 +0100	[thread overview]
Message-ID: <de042a7e-f9eb-8fe0-cad6-b3277e79b9c6@redhat.com> (raw)
In-Reply-To: <87r0vleykh.fsf@suse.de>

On 23/01/2023 22.22, Fabiano Rosas wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
>> On 23/01/2023 14.32, Fabiano Rosas wrote:
>>> Thomas Huth <thuth@redhat.com> writes:
>>>
>>>> On 20/01/2023 20.44, Fabiano Rosas wrote:
>>>>> These leaks can be avoided:
>>>>>
>>>>>     759 bytes in 61 blocks are still reachable in loss record 56 of 60
>>>>>        at 0x4034744: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>>        by 0x4A88518: g_malloc (in /usr/lib64/libglib-2.0.so.0.7000.5)
>>>>>        by 0x4AA313E: g_strdup (in /usr/lib64/libglib-2.0.so.0.7000.5)
>>>>>        by 0x12083E: qtest_get_machines (libqtest.c:1323)
>>>>>        by 0x12098C: qtest_cb_for_every_machine (libqtest.c:1348)
>>>>>        by 0x11556C: main (test-hmp.c:160)
>>>>>
>>>>>     992 bytes in 1 blocks are still reachable in loss record 57 of 60
>>>>>        at 0x4034744: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>>        by 0x4A88518: g_malloc (in /usr/lib64/libglib-2.0.so.0.7000.5)
>>>>>        by 0x120725: qtest_get_machines (libqtest.c:1313)
>>>>>        by 0x12098C: qtest_cb_for_every_machine (libqtest.c:1348)
>>>>>        by 0x11556C: main (test-hmp.c:160)
...
>> (Also, it's valgrind that you used, isn't it? - I wonder why it's
>> complaining here at all since the pointer to the memory should still be
>> valid at the end?)
> 
> valgrind is complaining about the memory not being explicitly freed at
> any point. I guess "leak" was not the most precise term to use in the
> commit message.

How did you run valgrind? For me, it does not really complain about the 
non-freed memory here since it is still reachable. The only difference that 
I see is in the summary. Without your patch:

     still reachable: 27,471 bytes in 152 blocks

with your patch:

     still reachable: 25,713 bytes in 88 blocks

... but that IMHO doesn't really hurt, since the memory is not really 
leaked, i.e. the memory usage won't increase during runtime here. So I fail 
to see which problem you're really trying to solve here, could you please 
elaborate?

  Thomas




  reply	other threads:[~2023-01-24  7:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 19:44 [PATCH] tests/qtest: Plug memory leaks in qtest_get_machines Fabiano Rosas
2023-01-23  7:55 ` Thomas Huth
2023-01-23 13:32   ` Fabiano Rosas
2023-01-23 19:49     ` Thomas Huth
2023-01-23 21:22       ` Fabiano Rosas
2023-01-24  7:25         ` Thomas Huth [this message]
2023-01-24 12:45           ` Fabiano Rosas
2023-01-24 13:04             ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de042a7e-f9eb-8fe0-cad6-b3277e79b9c6@redhat.com \
    --to=thuth@redhat.com \
    --cc=farosas@suse.de \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).