QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
    - Compiling and Debugging
      Let's start by looking at some things you should consider when you start to write a program for the QNX OS.
    - QNX OS Architecture and Concepts
      The QNX OS architecture consists of the microkernel and several cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX OS.
    - Processes
      Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
    - Multicore Processing
      Multiprocessing systems, whether discrete or multicore, can greatly improve your applications' performance.
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) and QNX compressed filesystems, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Handling Hardware Interrupts
      This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali) In the Process Manager chapter of the System Architecture guide, we looked at how the OS manages memory. This chapter describes how you can work with memory.
      - Memory objects
        A memory object is a container for physical memory.
      - Memory management in QNX OS
        Let's consider memory management in general.
      - Memory initialization
        Memory initialization happens when physical pages are associated with virtual addresses via mmap() calls.
      - Dynamic memory management
        Let's examine how the heap is used for dynamically allocated memory.
      - Typed memory
        Your system's startup program can reserve memory pools to be used for special purposes, such as graphics. These pools are separate from SYSRAM.
      - Shared memory
        Shared memory is an efficient way to share data among different processes.
      - Heap analysis
        If you develop a program that dynamically allocates memory, you're also responsible for tracking any memory that you allocate whenever a task is performed, and for releasing that memory when you no longer need it. If you fail to track the memory correctly, you may introduce memory leaks or unintentionally write to an area outside of the allocated memory space.
        Heap corruption
        Heap corruption occurs when a program damages the allocator's view of the heap.
        Detecting and reporting errors
        The primary goal for detecting heap corruption problems is to correctly identify the source of errors and fix them to avoid getting faults in the allocator at some later time.
        Using the librcheck library
        Configuring librcheck for Memory Analysis
        Controlling the level of checking
        You can use environment variables or the mallopt() function to enable extra checks within the librcheck library.
        Specifying an error handler
        Typically, when the library detects an error, it displays a diagnostic message, and the program continues executing. In cases where a critical error is encountered, an error message is printed and the program is aborted (via abort()).
        Caveats
        Manual checking (bounds checking)
        There are times when it may be desirable to obtain information about a particular heap buffer or print a diagnostic or warning message related to that heap buffer.
        Memory leaks
    - Freedom from Hardware and Platform Dependencies
      The QNX OS can run on many different hardware platforms. The way in which applications can access peripheral devices and how data is stored varies between platforms. This chapter explains our solutions for minimizing the impact of such platform dependencies.
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
    - Glossary
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Detecting and reporting errors

QNX SDP8.0Programmer's GuideDeveloper

The primary goal for detecting heap corruption problems is to correctly identify the source of errors and fix them to avoid getting faults in the allocator at some later time.

The first step to achieving this goal is to create an allocator that can determine whether the heap is corrupted on every entry into the allocator, whether it's for an allocation request or for a release request. For example, on a release request, the allocator should be capable of determining whether:

the pointer given to it is valid
the associated block's header is corrupt
either of the neighboring blocks is corrupt

To detect heap corruption, we provide a replacement library for the standard allocator that can keep additional block information in the header of every heap buffer. You can use this replacement library, which is implemented by the librcheck.so shared object and referred to simply as librcheck, while testing an application to help isolate any heap corruption problems.

When this allocator detects a source of heap corruption, it can print an error message indicating:

the point at which the error was detected
the program location that made the request
information about the heap buffer that contained the problem

The library technique can be refined to also detect some sources of errors that may still elude detection, such as memory overruns or underruns, that occur before the corruption is detected by the allocator. This may be done when the standard libraries are the vehicle for the heap corruption, such as an errant call to memcpy(). In librcheck, the standard memory manipulation functions and string functions are replaced with versions that use the information in this library to determine if their arguments reside in the heap and if they would cause the bounds of the heap buffer to be exceeded. Under these conditions, the functions can then call the error-reporting functions to provide information about the source of the error.

Page updated: March 05, 2025