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 the code for the shared libraries. If more than one process uses the same library, then the virtual segment containing its code will be 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 — This segment contains memory required for function stacks (one stack for each thread).
Heap — This segment contains all memory dynamically allocated by a process.
Shared Heap — Contains other types of memory allocation, such as shared memory and mapped memory for a process.

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, is it unlikely to return any noticeable result). Techniques for optimizing a particular type of memory are also dramatically different.

For information about obtaining process memory distribution details, see Inspecting your process memory distribution.

The main system allocator has been instrumented to keep track of 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 debug version of the malloc library (librcheck.so). 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, memmove). 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 debug version of the malloc library uses more memory than the nondebug version. When tracing all calls to malloc, the library requires additional CPU overhead to process and store the memory-trace events.

Note: Be sure to occasionally check the Downloads area on our website for updated versions of the debug malloc library.

The QNX Memory Analysis perspective can help you pinpoint and solve various kinds of problems, including: