Understanding Memory Profiling

The Memory Profile viewer displays a record of improper memory usage within the application of interest.

To read the Memory Profiling report:

  1. Select the Memory Profile tab.

First, block and byte memory use is summarized for you in a bar chart, immediately followed by a textual description to the same information. What you have is a record of:

If any memory errors were detected, or if any warnings are warranted, those comments are listed next. The Report Window on the left hand side of the screen gives you a quick look at the contents of the report - your manual interaction with the UMTS base station via the simulated mobile phone has resulted in the creation of (BaseStation)<timestamp>. If you click an item in the Report Window, the memory profiling report will scroll to the proper location.

  1. On the Report Window, left-click the ABWL error.

Apparently, the memory profiling feature has detected a Late Detect Array Bounds Write (ABWL) - in other words, the UMTS base station code attempted to add data to an array element that does not exist. This error report is followed by the call stack, with the last function in the call stack listed first. Notice how each function is highlighted; clicking on the functions in the call stack will jump you to the relevant source code. Each source code file is highlighted at the line in which memory was requested - in this particular case, some part of the UMTS base station code overwrote an array, thereby causing the ABWL error.

The ABWL is followed by one File In Use (FIU) and four Memory Leak (MLK) warnings. The File In Use warning references <internal use> - in other words, the file is being used by the memory profiling feature. As for the memory leaks - well it looks like you have some work to do here. Although it is conceivable the memory leak occurs by design (e.g. perhaps some clean-up code has not yet been written), assuredly the UMTS base station is not meant to have any.

Finally, the exit code is printed - look for the informational/warning note in the viewer starting with the words Program exit code. The memory profile report lists the exit code as a warning if it is of any value other than 0.

Notice how easily this information has been acquired; no work was required on your part. A real advantage is that memory leak detection can now be part of your regression test suite. Traditionally, if embedded developers looked for memory leaks at all, it was done while using a debugger - a process that does not lend itself to automation and thus repeatability. The memory profiling feature lets you automate memory leak detection.

And again, the identical functionality can be used on either your host platform or on your embedded target.

Further Work