On Mon, Jul 20, 2020 at 10:50:23AM +0300, Vladimir Sementsov-Ogievskiy wrote: > 20.07.2020 09:16, Thomas Huth wrote: > > > > Hi, > > > > looks like the LeakSanitizer spotted a memory leak in the bitmap related > > code ... not sure why it just triggered with Richard's pull request, and > > I can also not reproduce it... But since there is a nice backtrace in it > > and there have been some bitmap-related patches recently, could you > > maybe have a look whether this rings a bell by any chance: > > > > https://gitlab.com/qemu-project/qemu/-/jobs/645799805#L3282 > > > > Hi! Hmm. bitmap.c/bitmap.h is a simple bitmap library, which was not changed > this > year. The last commit I see is about a year ago. > > So, I assume the problem should be somewhere below in the stack trace. > > I don't know this code, but try to look at: > > OK, sanitizer reports that we loose the memory allocated at exce.c:2219, i.e. > > new_blocks->blocks1[j] = bitmap_new(DIRTY_MEMORY_BLOCK_SIZE); > > Hmm. And where is this bitmap released? I can't find the place. May be the > leak > was introduced in far 5b82b703b69acc67b7 with this bitmap_new()? Add Stefan to > CC.
g_free_rcu() is used when ram_list->dirty_memory[] is extended, so the leak is not dangerous. There is no cleanup function for the global ram_list. I'll investigate writing a patch to clean up ram_list fields. Thanks, Stefan
signature.asc
Description: PGP signature
