Memory Leaks

The Profiler control, showing the count of memory allocations and the count of operations that are memory free.

A well behaved program.

Memory leak detection is a road well traveled. Although many other good options are available, we believe our approach has major benefits, such as:

No changes at all to existing project build
No header files required by the project code
No runtime dependencies to worry about
No system configuration to think about

Usage

A person would use this mode to track memory leaks in an application or in an activity within the application. A memory leak from the Profiler's point of view is a successful call made to a memory allocation function that returns a memory address for which no matching call is made to free that address.

Operation

The Memory Leak detection works through hooking. The memory routines of the process are hooked to track when memory is both allocated and freed. Call Stacks are captured at the point of the allocation and this information is collated in Enterprise Architect to produce a report in the form of a Call Graph. Capture is controlled; that is, the hooking mechanisms can be enabled or disabled on demand.

Depending on the type of program and its memory consumption, you could employ an appropriate strategy. For small programs, you might track the program from start to finish. For larger windowed programs, you would probably do better by toggling capturing before and after a specific task to avoid tracking too much data.

Results

Results can be produced at any time during the session; however, capture must be disabled in order for the Report button to become active. It is your decision how long you let the Profiler run. You enable the Report button by either pausing capture or stopping the Profiler altogether.

Results are displayed in a Report view. The report initially opens with two tabs visible; a single weighted Call Graph and a Function Summary. The Call Graph depicts all the Call Stacks that led to memory allocations, and are aggregated and weighted according to the frequency of the pattern.

Reports can contain a variable amount of 'noise'. To focus on an area you have specific concerns for, locate a function known to you in the summary report and use that to navigate directly into the line in the graph where it is featured.

Requirements

For best results, the image and its modules should be built with debug information included, and without optimizations. Any module with the Frame Pointer Omission (FPO) optimization is likely to produce misleading results.