Hi; I'm looking at a memory leak apparently in the host memory backend code that you can see from the qmp-cmd-test. Repro instructions:
(1) build QEMU with '--cc=clang' '--cxx=clang++' '--enable-debug' '--target-list=x86_64-softmmu' '--enable-sanitizers' (2) run 'make check'. More specifically, to get just this failure ('make check' on current head-of-tree produces some other unrelated leak errors) you can run the relevant single test: (cd build/asan && ASAN_OPTIONS="fast_unwind_on_malloc=0" QTEST_QEMU_BINARY=./qemu-system-x86_64 ./tests/qtest/qmp-cmd-test --tap -k -p /x86_64/qmp/object-add-failure-modes) The test case is doing a variety of object-add then object-del of the "memory-backend-ram" object, and this add-del cycle seems to result in a fairly large leak: Direct leak of 1572864 byte(s) in 6 object(s) allocated from: #0 0x555c1336efd8 in __interceptor_calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-x86_64+0x218efd8) (BuildId: fc7566a39db1253aed91d500b5b1784e0c438397) #1 0x7f5bf3472c50 in g_malloc0 debian/build/deb/../../../glib/gmem.c:161:13 #2 0x555c155bb134 in bitmap_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitmap.h:102:12 #3 0x555c155ba4ee in dirty_memory_extend system/physmem.c:1831:37 #4 0x555c15585a2b in ram_block_add system/physmem.c:1907:9 #5 0x555c15589e50 in qemu_ram_alloc_internal system/physmem.c:2109:5 #6 0x555c1558a096 in qemu_ram_alloc system/physmem.c:2129:12 #7 0x555c15518b69 in memory_region_init_ram_flags_nomigrate system/memory.c:1571:21 #8 0x555c1464fd27 in ram_backend_memory_alloc backends/hostmem-ram.c:34:12 #9 0x555c146510ac in host_memory_backend_memory_complete backends/hostmem.c:345:10 #10 0x555c1580bc90 in user_creatable_complete qom/object_interfaces.c:28:9 #11 0x555c1580c6f8 in user_creatable_add_type qom/object_interfaces.c:125:10 #12 0x555c1580ccc4 in user_creatable_add_qapi qom/object_interfaces.c:157:11 #13 0x555c15ff0e2c in qmp_object_add qom/qom-qmp-cmds.c:227:5 #14 0x555c161ce508 in qmp_marshal_object_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qapi/qapi-commands-qom.c:337:5 #15 0x555c162a7139 in do_qmp_dispatch_bh qapi/qmp-dispatch.c:128:5 #16 0x555c16387921 in aio_bh_call util/async.c:171:5 #17 0x555c163887fc in aio_bh_poll util/async.c:218:13 #18 0x555c162e1288 in aio_dispatch util/aio-posix.c:423:5 #19 0x555c1638f7be in aio_ctx_dispatch util/async.c:360:5 #20 0x7f5bf3469d3a in g_main_dispatch debian/build/deb/../../../glib/gmain.c:3419:28 #21 0x7f5bf3469d3a in g_main_context_dispatch debian/build/deb/../../../glib/gmain.c:4137:7 #22 0x555c163935c9 in glib_pollfds_poll util/main-loop.c:287:9 #23 0x555c16391f03 in os_host_main_loop_wait util/main-loop.c:310:5 #24 0x555c16391acc in main_loop_wait util/main-loop.c:589:11 #25 0x555c14614917 in qemu_main_loop system/runstate.c:801:9 #26 0x555c16008b8c in qemu_default_main system/main.c:37:14 #27 0x555c16008bd7 in main system/main.c:48:12 #28 0x7f5bf12fbd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 My initial suspicion here is that the problem is that TYPE_MEMORY_BACKEND has a UserCreatableClass::complete method which calls HostMemoryBackend::alloc, but there is no corresponding "now free this" in instance_finalize. So ram_backend_memory_alloc() calls memory_region_init_ram_flags_nomigrate(), which allocates RAM, dirty blocks, etc, but nothing ever destroys the MR and the memory is leaked when the TYPE_MEMORY_BACKEND object is finalized. But there isn't a "free" method in HostMemoryBackendClass, only an "alloc", so this looks like an API with "leaks memory" baked into it. How is the freeing of the memory on object deletion intended to work? thanks -- PMM