Memory leaks

A memory leak is a portion of heap memory that was allocated but not freed, and the reference to that area of memory can't be used by the application any longer. Over time, your program may consume more memory than it actually needs. Typically, the elimination of a memory leak is critical for applications that run continuously because even a single byte leak can crash a mission critical application that runs over time.

In its mildest form, a memory leak means that your program uses more memory than it should. BlackBerry 10 OS keeps track of the exact memory your program uses, so once your program terminates, the system recovers all the memory, including the lost memory.

If your program has a severe leak, or leaks slowly but never terminates, it could consume all memory, perhaps even causing certain system services to fail.

There are two types of memory leaks: apparent and subtle. An apparent memory leak is a chunk of heap memory that's never referred from active memory, a subtle leak is memory that is still referred to but shouldn't be, i.e. a hash or dynamic array holds the references.

The Memory Analysis tool can help you to detect both of these types of leaks.

Memory Analysis tooling consists of IDE Visualization tools and a runtime library called librcheck.so. The library overrides the allocator and implements an algorithm that's able to detect memory leaks in the runtime. You don't need to re-compile your program to enable error detection; the library can be pre-loaded at runtime if you're running your program with Memory Analysis enabled.

There are a few ways of finding memory leaks using the QNX Memory Analysis tool:

To enable leak detection from the IDE:

  1. From an existing launch configuration, select the Tools tab.
  2. Select Add/Delete Tool.
  3. Select Memory Analysis and click OK.
  4. The easiest way to detect leaks is to specify a time interval for leak detection. For example, if you want to enable leak detection every minute, enter 60000 (for 60 seconds) in the Perform leak check every (ms) field.

    Screen showing error settings in the Memory Analysis tool.

  5. Select the Switch to this tool's perspective on launch' option.
  6. After enabling Memory Analysis in a launch configuration, run that configuration.

There are a few other ways to enable memory analysis, including attaching to a running application or postmortem analysis. For more information about these and other launch options, see Launch your program with Memory Analysis.

The following tools in the Memory Analysis perspective can help you find and fix memory leaks:

  • Memory Problems view — shows you all found "apparent" memory leaks (unreachable blocks). Screen showing the Memory Problems view.
  • Memory Errors view — shows you all of the instances where your program allocates, reallocates, and frees memory. The view lets you hide allocations that have a matching deallocation; the remaining allocations are either still in use or forgotten. For detailed information, see Inspect outstanding allocations.

For detail information about enabling memory leaks detection and understanding the findings, see the information in the sections below.

Enable leak detection

To run leak a detection application and all user specific shared libraries, it should be compiled with debug information, and the target should have librcheck.so library installed.

To enable leak detection, from the IDE:

  1. From an existing launch configuration, select the Tools tab.
  2. Select Add/Delete Tool.
  3. Select Memory Analysis and click OK.

    Screen showing the Tools Selection dialog box in the Memory Analysis Tool.

  4. On the Memory Analysis tab, expand Memory Tracing and ensure that tracing is enabled. If tracing isn't enabled, leaks would be detected, but wouldn't carry out the allocation backtrace, which makes it almost impossible to identify.
  5. Select the Perform leak check when process exits option if your application exists normally.
  6. Select the Switch to this tool's perspective on launch' option.
  7. After enabling Memory Analysis in a launch configuration, run that configuration.

There are a few other ways to enable memory analysis, including attaching to a running application or postmortem analysis. For more information about these and other launch options, see Launch your program with Memory Analysis.

Detect leaks on demand during program execution

In a continuously running application, the following procedure enables memory leak detection at any particular point during program execution:
  1. Find a location in the code where you want to check for memory leaks, and insert a breakpoint.
  2. Launch the application in Debug mode with the Memory Analysis tool enabled.
  3. Change to the Memory Analysis perspective.
  4. Open the Debug view so it is available in the current perspective.
  5. When the application encounters the breakpoint you specified, open the Memory Analysis session from the Session View (by double-clicking) and select the Setting page for the Session Viewer.
  6. Click the Get Leaks button.
    Before you resume the process, take note that no new data will be available in the Session Viewer because the memory analysis thread and application threads are stopped while the process is suspended by the debugger.
  7. Click Resume in the Debug view to resume the process' threads.
    If leaks did not appear on the Memory Problems tab of the Session Viewer, either there were no leaks, or the time given to the control thread (a special memory analysis thread that processes dynamic requests) to collect the leaks was not long enough to perform the command; and was suspended before the operation completed.
  8. Switch to the Errors page of the viewer, to review information about collected memory leaks.

Besides apparent memory leaks, an application can have other types of leaks that the memory Analysis tool cannot detect. These leaks include objects with cyclic references, accidental point matches, and left-over heap references (which can be converted to apparent leaks by nullifying objects that refer to the heap). If you continue to see the heap grow after eliminating apparent leaks, you should manually inspect some of the allocations. You can do this after the program terminates (completes), or you can stop the program and inspect the current heap state at any time using the debugger.

Interpret leaks

The message for a memory leak includes the following type of useful information detail:

  • Message: varies
  • Severity: LEAK
  • Pointer: lost pointer
  • TrapFunction: blank
  • Operation: malloc, realloc, alloc, calloc — how memory was allocated for this leak
  • State: empty or in use

For a list of error messages returned by the Memory Analysis tool, see Summary of error messages for Memory Analysis.

How to address resource (memory) leaks

To address resource leaks in your program, ensure that memory is deallocated on all paths, including error paths.

Example

The following code shows an example of a memory leak:

int main(int argc, char ** argv){
            char * str = malloc(10);
            if (argc>1) {
            str = malloc(20);
            // ...
            }
            printf("Str: %s\n",str);
            free(str);
            return 0;
            }

Last modified: 2013-12-21

comments powered by Disqus