Memory Checker in Inspector XE will monitor some memory allocation/deallocation APIs, such malloc/free, new/delete, etc. If memory allocation returned memory start address in stack avariables (pointers), they should be deallocated when exit functions.
If your classes andother classes use standard memory allocation/deallocation, memory leakscan be detected.
You are right.
Since Update 6, the tool supports to report "Memory Growth" problem, it occurs when a block of memory is allocated but not deallocated within a specific time segment during application execution.
Here is my simple example code for testing:
Create an Inspector XE projecton GUI to run"Locate MemoryProblem" with program, click "Start" button, afterawhile click "Set Transaction Start"...run program awhile again...click "Set Transaction End". Finally click "Stop" button to terminate application, to get report below.
What I saw is "Memory Growth" problem given, and problematical source allocation was pointed out. However
Object Size is empty, so we can detect it butcannot find exactsize for this memory growth problem.
I will verify this problem with engineering team, and update this soon.
How do you define that value? Howcould I know it in advance?
1. Thereare dynamicalgorithms and it is impossible to predict how much memory will be needed for
processing, when it will be requested and when it will be released.
2. Some applications are pre-allocating huge amounts of memory in advance,then usememory and before
exit deallocate.In that scenario there are no Memory Growth problem and there are no Memory Leaks.
So, the Memory Growth concept looks confusing.
3. Some applications are pre-allocating huge amounts of memory in advance,then usememory and before
exit "drop" itand it iscalled as Enforced Memory Leaks. It makes exit for the applicationfaster.
PS: I'll provide latera screenshot of howEnforced Memory Leaks works.
Note: It takesmore thentwo minutes forthe test application to release almost 2GB of previously allocated memory.
Thanks for illustrating the memory drop concept, it is interesting. The "Memory growth" problem finding is intended to specific applications, mostly for "transactional". User uses it only if he know structure of his application (does it use pre-allocation etc). So if you certain there is some "transaction" that should not gain memory growth after finishing, you can use this functionality.
Finding memory growth is not intended for using during the whole application life period. These problems are found only during specified time period, between user-defined marks. If user doesn't press transaction start and stop buttons, the memory growth is not reported.