On Wed, 2016-04-27 at 10:38 +0100, Catalin Marinas wrote: > > Kmemleak tries to reduce the false positives to the detriment of more > false negatives.
:) > One way it does this is by having to scan the memory > twice and no changes to the leaked object (crc32) should have > happened. It also scans the task stacks which is another source of > false/stale pointers. The leak may eventually be reported but you > can't really be precise on when this would be. > Ok, fair enough. I don't remember if I asked it to scan twice, but anyway, I did convince myself separately (with prints) that it was leaked :) Thanks for the explanation! johannes