FastMM - Expected memory leaks

[Ulf Axelsson]

(Note: This is all based on the assumption that LeakAddress currently is
the address of the leaked data, not it's origin as far as I can tell)

I have been thinking some more about how to easily handle registering
expected memory leaks and have come up with the following two variants:

Either

RegisterExpectedMemoryLeak( const aAddress: Cardinal; const aClassName:
String = ''; const aCount: Integer = -1 );

RegisterExpectedMemoryLeak( const aUnit: String; const aLine: Integer;
const aClassName: String = ''; const aCount: Integer = -1 );

In both cases aClassName would be the (optional) name of the class and
aCount the (optional) expected number of leaks. I have chosen to use
aClassName as a String instead of TClass as I assume that a lot of the
expected leaks might be inside implementation blocks in code for which
one do not have source or cannot modify the source, the class type is
not available for those (right?).

Chosing the first version would make it relatively easy to detect if a
leaks is an expected leak. Just walk the stack at the time of the leak
and check if the given address is a return address on it.

Chosing the other version would require the debug info helper (and some
knowledge of it's output format to find the line) before doing the
comparison during the stack walk. But it would be possible to provide a
set of known leaks for each D RTL/VCL version in automatically chosen
include files along with the MM as the "address" no longer is
application dependent.

Unregistering a memory leak should not really be necessary with this
approach.

I hit a small wall on how to implement this though. I assume that the
current code avoids any dynamic allocation for registered leaks because
it does not want to have "private" data mixed with application data and
also avoid all kinds of possible bugs resulting from that? If the number
of leaks get somewhat larger I would need some fast way of checking if
an adress (or unit + lineno) is among the expected leaks. Building a
binary tree in a static array is possible but slightly cumbersome...
I am also not entirely certain on how to find find the stacktrace when
it is time to check for leaks. For example at line 5938 (4.27) the
TFullDebugBlockHeader is stored at the beginning of the LDataPtr block
(?), but is it verified valid at that stage of the check or does that
come later?

An how deep in the stack trace should it be necessary to search? One
would have to step over any references to GetMem etc. but should the
user have to pinpoint the leak exactly or should it be possible to give
an address on a higher level in the call stack?

Comments on all this?

[Pierre le Riche]

Hi Ulf,

Post by Ulf Axelsson
aCount the (optional) expected number of leaks. I have chosen to use
aClassName as a String instead of TClass as I assume that a lot of the

I like this idea a lot.... definitely worth implementing.

Post by Ulf Axelsson
Chosing the first version would make it relatively easy to detect if a
leaks is an expected leak. Just walk the stack at the time of the leak and
check if the given address is a return address on it.

FastMM4 only stores stack traces in FullDebugMode (Storing stack traces is
slow and uses a lot of extra memory.) Both your suggestions seem to require
stack traces. The leak checking has to work in performance mode as well, or
it will be less useful than it is now.

Regards,
Pierre

[Ulf Axelsson]

Post by Pierre le Riche

Post by Ulf Axelsson
Chosing the first version would make it relatively easy to detect if a
leaks is an expected leak. Just walk the stack at the time of the leak and
check if the given address is a return address on it.

FastMM4 only stores stack traces in FullDebugMode (Storing stack traces is
slow and uses a lot of extra memory.) Both your suggestions seem to require
stack traces. The leak checking has to work in performance mode as well, or
it will be less useful than it is now.

Yes, this would require stack traces, but only if you want to filter out
expected leaks this way.

But thinking a bit more I come to the conclusion that none of this
filtering should be done within the memory manager, it has enough other
things to handle. I would be easier programmingwise to do any kind of
filtering on the leak report with an external program. One would not
have to handle storage of the expected leak definitions within the
memory manager and could use any kind of (possibly memory intensive)
filtering approach. To be able to filter the way I want, the report
would need to contain stack traces but that would have no additional
effects on the MM itself.

One might possibly want to add some additional "markers" in the log file
to make the parsing of it a bit more robust in the filter, but that is
more or less trivial.

Regards,
Ulf