Integrated tools

The IDE works with the GNU Debugger (GDB) and many runtime analysis tools, some of which are made by QNX and others by a third party. Using these tools, the IDE can report memory errors, heap usage, and function runtimes, and display kernel event trace data and target state information.

System Information, GDB, and the System Profiler are helpful in all debugging use cases—improper program results, process hanging, and process crashing. The last two tools can be used concurrently with the memory-analyzing and profiling tools, which find more specific problems.

For debugging improper program results and crashes, the Memory Analysis, Valgrind Helgrind, and Valgrind Memcheck tools are useful. For detecting the cause of a process hanging, the Application Profiler and System Information are helpful.

Note: Code Coverage isn't primarily used for debugging or optimization—its purpose is to measure the effectiveness of unit tests. Valgrind Cachegrind also isn't intended for debugging but instead helps you improve performance by optimizing cache usage.

Table 1. IDE tool support for debugging use cases
Tool	Debugging capabilities	Use cases	Advantages	Drawbacks
Application Profiler	When run in sampling mode, takes execution position snapshots (i.e., the current address being executed) at regular intervals. The execution positions provide a summary of where in the code the program is spending most of its time.	Process hanging	tells you the threads where the program is getting stuck without requiring you to step through the code sampling mode has low overhead, so the data aren't biased towards particular functions (e.g., short or frequently called functions)	reveals limited information; the sampling data tell you on average how often certain threads run, but nothing about how they use memory or interact inaccurate over short time intervals, because the sampling size is small
GDB	Lets you step through the code to see which paths are followed, how variable values change over time, and whether certain lines of code are reached. You can also debug core files, to see what a program was doing when it crashed.	Improper program results Process hanging Process crashing	gives a “white box” view of the program's state as it runs so you can determine the exact code changes needed to fix any problems works well with other tools because it stops execution when a crash occurs, which lets you run another tool by loading a core file, you can work backwards from a crash to determine its cause, without tracing the program's entire execution	requires you to have a good idea about which areas of code are causing problems (except with core files) starting and stopping execution in the debugger changes thread timing, making some situations hard to reproduce core files show the crash symptoms but don't always reveal their cause (e.g., errors can occur long after a bad memory allocation)
Memory Analysis	Tracks allocation and deallocation operations and provides data to the IDE so it can report memory leaks and other common errors such as buffer overruns.	Improper program results Process crashing	doesn't require recompiling the program and is easily configured in the launch configuration has much less overhead than other tools (i.e., only a 30% increase in memory usage and a performance cost of 3 to 5%)	finds relatively few errors; for instance, a source pointer containing a bad address passed to memcpy() is reported as an error, but uninitialized memory isn't
System Information	This IDE perspective provides memory, CPU, and resource usage data about the processes on a target. It also displays thread states, so you can see if a process is hanging because one of its threads is blocked or busy.	Process hanging	quick and easy to use; doesn't require any launch configuration or build support, and you can switch to this perspective and see the target information at any time	tells you which threads are blocked or busy (and possibly causing a process to hang) but not why
System Profiler	Displays event data generated by the instrumented kernel running on a target. These data include process- and thread-level metrics on CPU consumption, execution times, and the number of messages sent, which gives you an idea of the event sequence behind a program failure.	Improper program results Process hanging Process crashing	lets you find problems related to the interaction of many processes or threads, by providing data about message passing and other IPC mechanisms CPU statistics can quickly tell you when a particular thread began monopolizing a CPU, which is often the cause of a process hanging can be used concurrently with other analysis tools, because you can start a kernel event trace no matter which processes and tools are running	less precise way of debugging—it's better to debug a core file or trace the program's execution with GDB to find where in the code a problem occurs even short kernel event traces that last only a few seconds produce a lot of data, making it hard to find insightful information; determining how to best filter the data can be complex
Valgrind Helgrind	Finds thread synchronization problems in programs that use pthreads, by detecting memory locations accessed by more than one thread but without proper locking or synchronization.	Improper program results Process crashing	detects multiple classes of synchronization problems: POSIX API misuses, lock ordering problems that can cause deadlock, and data races; this helps you fix hard-to-find timing bugs and the program's design	performance can be very poor; slowdowns up to 100 times aren't unusual in the present version, for lock order errors, the tool prints only 2 cycles instead of the complete lock cycle
Valgrind Massif	Takes regular heap snapshots and outputs data describing heap usage over time and where most memory is being allocated. These data let you see which functions use too much memory as well as the heap contents any time the program crashed.	Improper program results Process crashing	helps you find both design and implementation bugs, by highlighting memory gluttons as well as leaks	sends session data to IDE only upon program termination, so you can't monitor heap consumption in real time imposes significant overhead on programs, making them run about 20 times slower than usual
Valgrind Memcheck	Detects memory management problems by checking all reads and writes of memory. This tool finds memory leaks, bad frees, overlapping blocks in source and destination pointers, use of uninitialized values, and accesses to improper memory regions.	Improper program results Process crashing	very precise; can detect invalid memory accesses at the byte level and uses of uninitialized memory at the bit level informative; reports errors as soon as they're detected, giving the source line numbers at which they occurred and a backtrace of the current position	significant performance impact; instrumented programs run at one tenth normal speed (or slower) and use two to three times more memory can't detect some out-of-bounds memory accesses (e.g., if the first access to an array is beyond the last element)