Troubleshooting the IDE

The following table answers some common IDE questions you might have:
Question Answer
Why is nothing being displayed in the IDE?
One of the goals of the IDE is to simplify and automate work for developers, so it needs to be told what to do. There are two settings (in both the per-project and global default settings) that are particularly important:
  • The binary parser setting lets IDE tools (like the Debug Launcher) filter binary code from source code. When you see the Binary Parser task running in the progress bar, this background thread is actively trying to determine which files are binaries and which aren't. When you select Search, this provides the content for the Binaries folders in the Project Explorer view and for the Debug Launcher file selector. If you don't see anything in either of these areas, then the binary search hasn't completed yet, or the binary parser is misconfigured (it should be QNX ELF).
  • The debugger setting. There are many debuggers available for use in different situations, and all QNX configurations should have an appropriate default setting. However, if your debugger is behaving unexpectedly (particularly with local or gdb remote target configurations), ensure the debugger is set as a QNX gdb type.
Do I need to convert my build process to match an IDE project? For nearly every type of existing code base with a build process, you'll want to choose the standard Makefile Project with Existing Code type because it simply calls out to an external build program to build the source (typically, it's make, but it could be JAM, ANT, dmake, or any other builder.)

If you start a project from scratch, using a QNX project type allows you to build for multiple processors (referred to as variants) with a single build based on the QNX recursive make framework (however, the binaries won't port well to other systems).

Managed Projects offer full IDE graphical control and configuration, and take advantage of the Eclipse framework (i.e., incremental compiles, links, and so on).

If you never intend to run your build from the IDE, only use the standard make type to identify the source as C/C++ source and to identify the binary types.

Do I need to convert my build to a QNX Momentics style project to use the IDE?

You need to create a project associated with your specific source and binaries requirements and associate this project with a workspace. However, this project doesn't have to be kept in the workspace; it can be anywhere you want.

The following are all valid locations:
  • The source resides in a project within the workspace, which is the default location when you create a new project, when you import the source into the IDE using File > Import or using a version control plugin, such as SVN.
  • The source is somewhere in the filesystem, and you want to overlay a project at that location. You can do this by creating a project and changing the default location from the workspace to the location of the source.
  • The source is somewhere in the filesystem, but you don't want to create any metadata files in that exact location. In this case, you first need to create an empty project. Next, you need to create a folder in that project and make the folder location point to the source in the filesystem, using the Advanced section of the Import dialog.
Why doesn't the debugger stop on breakpoints in my shared library code or step into my library functions? This generally occurs because gdb can't load symbols for this library. To check to see if symbols are loaded, open the Modules view. If your library appears in the view without a bug icon, its symbols are not loaded.
Why doesn't the debugger load symbols for my shared library?

First, it needs to find this library on the host. You usually have to specify the library path on the Shared Libraries tab in the Debugger tab of the launch configuration.

Second, the library file name must be the same as the so name with a lib prefix. You can check the so name in the properties of the library (.so file) or in the Binary Editor. For example, if your so name is but your file name is, gdb won't be able to match the two, because of the extra version number. To avoid this problem when debugging, don't use the so version number when you generate the so name.

Third, the library must be compiled with debug information.

After trying to launch a debug session from the IDE, why do I receive the error "Target is not responding (time out)"? Most likely, when you created an image for the target board, you did not include the pdebug utility in /usr/bin. This binary must be on the target to do remote debugging. Also, make sure that the qconn process has permission to run it.
When I try to launch a debug session, the IDE doesn't break on main and the program continues to run. Then, the debug session fails with a "Launch timeout" error. Why? If you have a lot of sources in your project, this may cause some gdb misbehavior while the IDE attempts to set search paths. If you compile on the same machine as you run the program, in the Launch Configuration, open the Source tab, delete the "Default" source lookup entry, then add an Absolute Path entry.
Can I use the gdb command-line console when the IDE is missing some gdb functionality? Yes, the gdb console is provided and it can redirect user input to the gdb command interpreter during a debugging session. To access the console, select Windows > Show View > Console. Then, click the Display Selected Console button () in the Console view and select the gdb console from the dropdown list. To execute gdb commands, type them in the console. For example, you can define breakpoints.
How can I attach the debugger to a running process?

First, you need to create a suitable launch configuration, by right-clicking the project you want to debug (in the Project Explorer), selecting Debug As > Debug Configurations > C/C++ QNX Attach to Remote Process via QConn (IP), then clicking the new icon () in the top left corner. Specify the binary under C/C++ Application, and the target in the Target Options list area, then click Debug. In the dialog that appears, select a running target process and click OK to attach the debugger to it.

In the Debug view, you can now use standard debugger controls such as resume, suspend, and step into. You can reuse the launch configuration for future debugging; you're only required to reselect the process (note that the binary must match).