https://bugs.kde.org/show_bug.cgi?id=455826
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #2 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
Note that the leak search algorithm is scanning the memory starting from "root"
memory zone (stacks, global variables, registers, ...).
During this scanning, any aligned piece of memory which happens to point at a
block will be considered as a pointer.
So, for example, if an integer variable happens to have the same bit
representation as the address of an allocated (but lost) block,
the leak search will not detect the lost block as a leak, because it has found
a "pointer" to this block.
So, possibly, depending on what the process does before exit, it might create
some bit patterns that look like a pointer.
The leak search algorithm might thus have false negative: some real leaks might
not be detected.
I do not see how the leak search algorithm could create a false positive lost
block (ignoring the possibility that the algorithm
is buggy of course).
Note also that monitor leak_check is just launching the same leak search
algorithms as used by client requests and used at exit.
As Paul said, more info (e.g. what does the leak stack trace look like ? Is
such a leak report plausible when it is detected) might clarify.
--
You are receiving this mail because:
You are watching all bug changes.
