Re: FastMM - Expected memory leaks
- From: Ulf Axelsson <ulf.axelsson@xxxxxxxxx>
- Date: Sun, 28 Aug 2005 10:26:27 +0200
Pierre le Riche wrote:
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 .
- References:
- FastMM - Expected memory leaks
- From: Ulf Axelsson
- Re: FastMM - Expected memory leaks
- From: Pierre le Riche
- FastMM - Expected memory leaks
- Prev by Date: Re: Fastcode MM B&V 0.50
- Next by Date: Re: FastCode - IntToStr B&V v0.12
- Previous by thread: Re: FastMM - Expected memory leaks
- Next by thread: Does Fast Code units compile in D5 Standard ?
- Index(es):
Relevant Pages
|
