Re: [PATCH v4 08/19] worktree: fix a trivial leak in prune_worktrees()

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

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

>> I'd rather see your reroll with the above addition of UNLEAK() than
>> without it, to fix the breakage.
>
> I don't mind that UNLEAK() being in-tree until a better fix for that
> leak, but doesn't the v5 I sent also address this?
>
> The issue was that I mis-marked a test as passing, when it only passed
> depending on my local compiler (-fsanitize=leak is fickle
> sometimes). Now that we're not marking that test as leak-free there's no
> need for the UNLEAK() for now, no?
>
> Or is there some edge case I didn't spot/notice?

The top-level singleton instance of "filter" that is used once and
never grows unbounded is a perfect use case for UNLEAK().  And with
it, the test DOES get leak-free, so it would be appropriate to keep
the PASSES variable added to the script (until it gets broken
again).

Or did you have any other uses of tools with leaks in the script,
other than the one that is fixed with the UNLEAK()?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux