Troubleshoot the IDE

The following table answers some IDE questions you might encounter:

Table 1. Troubleshooting issues in the IDE
Question	Answer
Why is nothing being displayed in the IDE?	Since one of the goals of the IDE is to simplify and automate work for developers, it needs to be told what to do. There are two settings (per project and global default settings) that are 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, that's the background thread iterating over the project content; its attempting to determine which files are binaries and which aren't. When you select Search (vs Browse), that's what provides the (virtual) content for the binaries folder in the Project Explorer view, as well as the content for the Debug Launcher file selection dialog . If you don't see anything in the Project Explorer view or the Debug Launcher, then the binary search has not come across anything yet and/or is not complete, or the binary parser is mis-configured (it should be QNX ELF). The debugger setting. There are many debuggers available for use in different situations, and while all of the QNX configurations should have an appropriate default setting. However, if your debugger is not behaving as expected (particularly with local or gdb remote target configurations), ensure that 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 with a build process, you'll want to choose the standard C (or C++) Make Project 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 Projects allows you to build for multiple processors (referred to as variants, including OS types) with a single build based on the QNX recursive make framework (however, they won't port well to other systems.) Managed make Projects provide a full IDE graphical control and configuration, and they 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?	The IDE wants you to narrow down the scope of what it needs to know about source, binaries, and so on. Therefore, you'll need to create a project associated with your specific requirements (source/binaries) and this project is in turn associated with a workspace; however, this project doesn't have to be in the workspace; it can be anywhere you want. The following are all valid locations: The source can reside in a project that is in the workspace, which is the default location when you create a new project, when you import source into the IDE using File > Import from the filesystem (which can perform a copy, but it's not necessary to do so), or by using a version control plugin, such as SVN. The source exists somewhere in the filesystem, and you want to overlay a project at that location. You can achieve 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 particular location. In this case, you want to create an empty project (either in the workspace, or another location). Next, you want 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. This is similar to a symlink in Unix, but this link only exists in the IDE workspace.
Why does the debugger not stop on breakpoints in my shared library code (or does not "step in" to functions from my library)?	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 does the debugger not load symbols for my shared library?	First, it needs to find this library in your shared library path on the host. You usually have to explicitly specify this on the Shared Libraries tab in the Debug 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 if you open the Properties view for the library (.so file) or open it in the Binary editor. For example, if your name is aaa.so.1 and your library name is libaaa.so, gdb will be unable to match the two, because of the extra version number. To avoid this problem when debugging, do not use the so version number when you generate the so name for your library. Third, the library has to be compiled with debug information.
After attempting to launch a debug session from IDE, you receive the error, "Target is not responding (time out)". Why would you be unable to debug?	Most likely, when you created an image for the target board you did not include pdebug program in /usr/bin. This binary is required to be on the target for remote debugging. Also make sure that the qconn process has permissions to run it.
You attempted to launch a debug session from the IDE, but it does not break on main, and the program appears to continue to run. After a short time, the IDE shows an error, "Launch timeout" and you can't debug.	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 it (the same host), in Launch Configuration, open the Source tab, delete the "Default" source lookup entry, and then add an Absolute Path.
Can you use the gdb command line console, when the IDE is missing functionality provided by gdb?	Yes, gdb console is provided and will redirect user input to the gdb command interpreter during a debugging session. To access the console, open the Console view from Windows > Show View, and then click on the gdb target of the current debugging session in the Debug view. Optionally, you can click on the Display Selected Console button (looks like a blue monitor) in a Console view, and then select a gdb console from the dropdown list. To execute gdb commands, type the command in the console, such as `show version`. An example of this functionality would be setting address breakpoints and catchpoints.
How can I attach the debugger to a running process?	First you need to create a launch configuration, select Run > Debug, select Attach to Process, and then click New (top left). Specify the project and binary for the configuration, select the target, and click Debug. The IDE will prompt you to select a process running on the selected target. Choose a process and click Ok to create the debug session. Now, you can use the regular debugger commands, such as resume, suspend, and step. You can reuse the same launch configuration for future use, you'' only be required to reselect the process Id (note that the binary also has to match).