Finding memory corruption with Memory Analysis

You can enable error checking for Memory Analysis and launch an application to find cases of memory corruption,
such as bad pointer values given to C library functions as well as out-of-bounds data writes.

Note:
You can run an application that uses librcheckfrom the command line. However, using the IDE is more convenient because the Memory Analysis tool automates
the requesting of data from this memory-tracing library and presents the results in a convenient format.

To find memory corruption with Memory Analysis:

In the launch bar, expand the Launch Configuration dropdown (which is in the middle) and select the project
for which you want to check memory.

In the Launch Target dropdown (on the right), select the target for running your application.

In the Launch Mode dropdown (on the left), select Check.

Note:
Although you can select Debug mode and manually enable Memory Analysis in the launch configuration, we recommend
that you don't run this tool at the same time as the GDB debugger because the setup is more complicated.
If you absolutely have to run both tools concurrently, you must follow the steps given in
Running Memory Analysis and the GDB Debugger concurrently instead of the remaining steps given
here.

To confirm that Memory Analysis is the active tool or to adjust how it checks for memory errors,
you must examine the launch configuration. To do this:

Click the Edit button () on the right of the Launch Configuration dropdown.

In the configuration editor window, click the Check tab on the right to access
the tool controls.

Ensure that the Memory Analysis radio button is selected, then uncheck the
Record memory allocation/deallocation events box in the
Memory Tracing panel.

The IDE switches to the QNX Analysis perspective. If necessary, it first builds the binary.
Then, the IDE uploads the binary and starts running it on the target, with librcheck loaded.
When this happens, a new session is created for storing the data produced by the librcheck library;
this session is displayed in the Analysis Sessions view.

The Memory Analysis tool lists corruption and other memory errors in the Memory Problems view,
which is displayed at the bottom. By default, errors for the entire program are listed but you can expand the
Analysis Sessions entry and click a program component (e.g., process, thread) to show only its errors.

In Memory Problems, all corruption errors contain a red X next to the ERROR keyword
and also provide an error description and the name of the function that trapped the error.
When Memory Analysis knows the exact location where memory was corrupted, the binary object, source file, and line of code
are also given. If the tool can't determine the corruption location (because the error was caught in another part of
the program), it can't provide those details.

You can click an error to see stack traces of the code that allocated the memory and the code that detected its
corruption. These stack traces are shown in the Memory Backtrace view displayed in the lower left
area. The depth of the detected call chain is restricted by the Limit back-trace depth to
field found in the Memory Errors panel.
The depth of the allocated call chain is based on the field with the same name but found in the
Memory Tracing panel.

In the following screenshot, the depth is set to 2 for detection traces and to 1 for allocation traces:

If you double-click an error in Memory Problems or a stack frame in
Memory Backtrace, the IDE opens the source file at the indicated line (when source file
information is available). This feature lets you quickly find where a memory block was allocated or corrupted.

Note:
You can run multiple Memory Analysis sessions concurrently, on the same application or different applications,
but you must specify distinct file or device output paths for these sessions in the
Advanced settings.