On Thu, 2019-06-06 at 06:44 -0400, John Ferlan wrote:
> On 6/4/19 8:46 AM, Andrea Bolognani wrote:
> > } else if (vm->def->cputune.emulatorpin) {
> > -cpumapToSet = vm->def->cputune.emulatorpin;
> > +if (virBitmapCopy(cpumapToSet, vm->def->cputune.emulatorpin) < 0)
>
> Now
On 6/4/19 8:46 AM, Andrea Bolognani wrote:
> In two out of three scenarios we were cleaning up properly
> after ourselves, but in the remaining one we were leaking
> cpumapToSet.
>
> Refactor the logic so that cpumapToSet is always a freshly
> allocated bitmap that gets cleaned up
On Tue, 2019-06-04 at 15:37 +0200, Ján Tomko wrote:
> On Tue, Jun 04, 2019 at 02:46:46PM +0200, Andrea Bolognani wrote:
> > In two out of three scenarios we were cleaning up properly
> > after ourselves, but in the remaining one we were leaking
> > cpumapToSet.
>
> Given that the leak was
On Tue, Jun 04, 2019 at 02:46:46PM +0200, Andrea Bolognani wrote:
In two out of three scenarios we were cleaning up properly
after ourselves, but in the remaining one we were leaking
cpumapToSet.
Given that the leak was introduced recently by commit 5f2212c, not mentioning
it here seems
In two out of three scenarios we were cleaning up properly
after ourselves, but in the remaining one we were leaking
cpumapToSet.
Refactor the logic so that cpumapToSet is always a freshly
allocated bitmap that gets cleaned up automatically thanks
to VIR_AUTOPTR(); this also allows us to remove
