Inspecting process memory

Typically, virtual memory occupied by a process can be separated into the following categories:

Code — Contains the executable code for a process and for the shared libraries. If more than one process uses the same library, then the virtual segment containing its code is mapped to the same physical segment (i.e., shared between processes).
Data — Contains a process data segment and the data segments for the shared libraries. This type of memory is usually referred to as static memory.
Stack — Contains memory required for function stacks (one stack for each thread).
Heap — Contains all memory dynamically allocated by a process.
Shared Heap — Contains other types of memory, such as shared memory and mapped memory for a process.

For information about obtaining process memory distribution details, see Inspecting process memory with the QNX System Information perspective below.

Note: It is important to know how much memory each individual process uses, otherwise you can spend considerable time trying to optimize the heap (i.e., if a process uses only 5% of the total process memory, it is unlikely to return any noticeable result). Techniques for optimizing different types of memory are also quite different.

The system allocator has been instrumented to monitor statistics associated with allocating and freeing memory. This lets the memory statistics module unobtrusively inspect any process's memory usage.

When you launch your program with the Memory Analysis tool, your program uses the librcheck.so library. Besides the normal statistics, this library also tracks the history of every allocation and deallocation, and provides cover functions for the string and memory functions (e.g., strcmp(), memcpy()). Each cover function validates the corresponding function's arguments before using them. For example, if you allocate 16 bytes, then forget the terminating NULL character and attempt to copy a 16-byte string into the block using the strcpy() function, the library detects the error.

The librcheck library uses more memory than the regular allocator. When tracing calls to malloc(), the library requires additional CPU overhead to process and store the memory-trace events.

The QNX Memory Analysis perspective can help you pinpoint and solve various kinds of problems, including memory leaks and memory errors.