[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should I delete created coroutines manually?
From: |
Stefan Hajnoczi |
Subject: |
Re: Should I delete created coroutines manually? |
Date: |
Tue, 18 Aug 2020 16:19:58 +0100 |
On Mon, Aug 17, 2020 at 2:13 PM Coiby Xu <coiby.xu@gmail.com> wrote:
> I'm working on vhost-user block device backend [1]. When I tested my
> patches on the latest version of QEMU (commit
> d0ed6a69d399ae193959225cdeaa9382746c91cc) with --enable-sanitizer turned
> on, the follow error will be thrown out,
>
> ==46631==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 312 byte(s) in 1 object(s) allocated from:
> #0 0x55d0a7813921 in calloc (qemu/qemu-storage-daemon+0x646921)
> #1 0x7f8bd6f7b591 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x4f591)
> #2 0x55d0a815f3fb in qemu_coroutine_create
> qemu/util/qemu-coroutine.c:75:14
> #3 0x55d0a817321e in vu_client_start
> qemu/util/vhost-user-server.c:225:23
> #4 0x55d0a816fcf3 in vu_accept qemu/util/vhost-user-server.c:341:5
> #5 0x55d0a7f1293f in qio_net_listener_channel_func
> qemu/io/net-listener.c:54:9
> #6 0x55d0a7efb0f3 in qio_channel_fd_source_dispatch
> qemu/io/channel-watch.c:84:12
> #7 0x7f8bd6f7e33f in g_main_context_dispatch
> (/usr/lib/libglib-2.0.so.0+0x5233f)
>
> I have to call qemu_coroutine_delete to eliminate this kind of errors.
qemu_coroutine_delete() is an internal API and shouldn't be called directly.
If you are sure that the coroutine terminated (returned from its entry
function) then the leak is probably caused by the following:
util/qemu-coroutine.c has a pool of Coroutine objects that are reused.
It's likely that the "leaked" object is in that pool.
I'm surprised that this issue hasn't been reported before, but
release_pool should be cleaned up when the program terminates.
Stefan