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

Reply via email to