qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory leak in bitmap code?


From: Stefan Hajnoczi
Subject: Re: Memory leak in bitmap code?
Date: Tue, 21 Jul 2020 13:05:16 +0100

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.

Looking at this more there are a bunch of exec.c resources that are not
freed at shutdown (system_memory, mutexes, etc). I don't think it is
worth freeing them, especially not for QEMU 5.1 since it needs to be
done very carefully to avoid dangling pointers in case something else
that hasn't been free is still referencing the resources.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]