Memory leaks

A memory leak is a part of heap memory that was allocated but not freed. The app can't reference that area of memory. Over time, your app might consume more memory than it needs. The elimination of a memory leak is critical for apps that run continuously because even a small leak can cause an app to fail.

BlackBerry 10 OS tracks the memory your app uses. When your app terminates, the system recovers all of the memory, including the lost memory.

If your app has a severe leak, or leaks slowly but never terminates, it could consume all of the memory, which might cause 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, that is, 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 Momentics 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 recompile your app to enable error detection. If you're running your app with Memory Analysis enabled, the library can be preloaded at runtime.

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

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

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

Memory Problems view
Shows you all of the apparent memory leaks (unreachable blocks)
Memory Errors view
Shows you all of the instances where your app allocates, reallocates, and frees memory. This 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.

Enable leak detection

To run leak a detection on an app, it should be compiled with debug information, and the target should have librcheck.so library installed.

To enable leak detection, from the Momentics IDE for BlackBerry:
  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 check box if your app closes normally.
  6. Select the Switch to this tool's perspective on launch check box.
  7. After enabling Memory Analysis in a launch configuration, run that configuration.

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.

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

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;
}

Detect leaks on demand during app execution

Follow these steps to enable memory leak detection in your app:

  1. Find a location in the code where you want to check for memory leaks, and insert a breakpoint.
  2. Start the application in Debug mode with the Memory Analysis tool enabled.
  3. Change to the Memory Analysis perspective.
  4. Open the Debug view so that it is available in the current perspective.
  5. When the app encounters the breakpoint you specified, open the Memory Analysis session from the Session view and select the Setting page for the Session Viewer.
  6. Click Get Leaks. Before you resume the process, new data will not 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. In the Debug view, click Resume to resume the process' threads. If leaks didn't 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. To review information about collected memory leaks, switch to the Errors page of the viewer.

An app 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 inspect allocations after the app terminates (completes), or you can stop the app and inspect the current heap state at any time using the debugger.

Test for memory leaks using the System Information Tool

To test a running process for memory leaks:

  1. In the System Information perspective, select the process to examine.
  2. Switch to the Malloc Information view to compare memory usage at specific times.
  3. Watch the Outstanding column and observe the value to see if it increases, or watch the graph in the Overview History tab.

In the example below, notice the steady growth in the chart. If the memory usage continues to increase over time, then the process is not returning some of the allocated memory.

Screen showing the observed trend of the steady increase in allocated memory.

Since memory leaks can be apparent or hidden, to know exactly what's occurring in your app, use the Memory Analysis tool to automatically find the apparent memory leaks type. A memory leak is considered apparent when the binary address of that heap block (marked as allocated) isn't stored in any of the process memory and current CPU registers any longer.

Last modified: 2014-11-17



Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus