NetBeans C/C++ Development Pack 5.5. Debugging.

Table of Contents.

    1. Overview.

    2. Breakpoints.

    3. Call Stack View.

    4. Locals View.

    5. Watches View.

    6. Sessions and Threads.

    7. Debugger Console.

    8. Integration with NetBeans Editor.

    9. Menu, Toolbar Buttons and Hot Keys.


1. Overview.

The NetBeans C/C++ Development Pack 5.5 has a debugging module, which is based on the GNU debugger "gdb". Debugger "gdb" is not bundled with the NetBeans C/C++ Development Pack, users have to install it separately. I tried several versions, and I can say that gdb 6.5 works better on Windows than all previous gdb versions. On Solaris and Linux gdb 6.4 works better than all previous gdb versions. Older versions also work, but not older than 6.1, and there are some problems, that are fixed in version 6.4. I tried to use gdb 6.5 on Linux, but found some strange problems, so I went back to gdb 6.4.

To use the NetBeans C/C++ Development Pack 5.5 on Windows, I installed the latest Cygwin release (1.5.22-1) with its "Devel" package, and got "GNU gdb (cygwin-special)". You can use the following commands to verify the version of Cygwin, gcc, make and gdb:

$ cygcheck -c cygwin
Cygwin Package Information
Package              Version        Status
cygwin               1.5.22-1       OK

$ cygcheck -c gcc
Cygwin Package Information
Package              Version        Status
gcc                  3.4.4-1        OK

$ cygcheck -c make
Cygwin Package Information
Package              Version        Status
make                 3.81-1         OK

$ cygcheck -c gdb
Cygwin Package Information
Package              Version        Status
gdb                  20060706-2     OK

On Linux ("SUSE LINUX Enterprise Server 9" or "Fedora Core release 3"), I use either "/usr/bin/gdb", which is gdb 6.1, or I use gdb 6.4, which I downloaded from and built myself.

On Solaris I use gdb 6.4, which I downloaded from and built myself. The "gdb" binaries for Solaris, such as the one available on (gdb 6.0), are too old to be used with the NetBeans C/C++ Development Pack 5.5. I also tried /usr/sfw/bin/gdb on Solaris Nevada (current Solaris release has bundled "gdb" 6.3.50), and it works very well.

I think the best way to get familiar with the NetBeans C/C++ Development Pack 5.5 and its debugging module is to play with sample projects. There are several C and C++ sample projects, in that ship with the product: HelloApp, Quote, Args, MP, Welcome, IO. When you create a new project, you can select any of these sample projects, and then modify it for your needs. I will use the projects "Welcome" and "MP" to illustrate the debugging features. A picture below shows the project "Welcome" in debugging environment on Windows XP. You can see "Watches" view (on left side, under "Projects" view), "Sessions" view, "Breakpoints" view, "Call Stack" view and "Locals" view. The editor window shows the source file with two breakpoints ("red squares" on left side at lines 28 and 33), a pointer to the current line ("green arrow" at line 29) and tooltip evaluation of selected expression ("argv[i]").

Debug Sample Project Welcome1

This is not a default layout for debugging windows, but it is easy to rearrange windows according to your preferences. To move a window you have to click on its label, drag and drop it to a new location. If you close any of these panels by accident, you can get it back by going to main menu: "Window > Debugging > ...".

2. Breakpoints.

Debugger "gdb" supports many types of breakpoints, but only two types of breakpoints are supported in this release of debugging module:
  • Line breakpoint without condition
  • Function breakpoint without condition
It is possible to set a conditional or any other breakpoint using direct dialog with gdb through the "GDB Debugger Console", but they are not supported by debugging module, so they may not be handled properly. A line breakpoint can be set and removed in the editor. Just click on a line number (or on gray area on left edge of a line). Also a line breakpoint can be set from main menu ("Run" > "New Breakpoint...") or from "Breakpoints" view.
What is interesting and may be unusual (and even inconvenient in some cases) is that all breakpoints are "global". They are not associated with a project, or a particular binary. They are not associated with a debugging session. They affect all projects, all binaries, all sessions. Once a function breakpoint is set on the function "main", it will apply to any project as soon as it gets into its "main" function. Once a line breakpoint is set in a source file, it will affect all projects that include this source file. All actions are also "global", i.e. they affect all projects. A picture below shows a "Breakpoints" view with all available actions:

Breakpoints view, available Actions

3. Call Stack View.

The "Call Stack" view shows function names and their locations (source files and line numbers):

Call Stack view, available Actions

Unfortunately it does not show parameters. This is a known problem and I hope it will be fixed in next release (IZ 87053).
What is nice is that the "Call Stack" view allows you to make any particular frame current. Double click on its entry in the "Call Stack" view, and the "Editor" will show the corresponding source file, the "Locals" view will show the corresponding local variables, and the "Watches" view will reevaluate the expressions according to this frame.
A picture below shows a modified "Welcome" project, stopped at a breakpoint in function "f2" (line 24). I changed the current call stack frame to "f1" (line 31), and we can see that the "Locals" view shows variables "m" and "n" (which belong to function "f1"), the "Watches" view reevaluated all watches, the "Editor" window shows the source of function "f1" and the tooltip evaluation also works in context of function "f1":

Call Stack, Changed current frame to 2

4. Locals View.

The "Locals" view shows structures and allows you to "chase" pointers.
A picture below shows a modified "Welcome" project, stopped at a breakpoint in function "main" (line 50). The "Locals" view shows the structure of the variable "node" (structure _Name):

Locals view, show structure, chase pointer

Unfortunately this feature is not very stable, and sometimes nested fields are shown as value (not recognized as fields).

5. Watches View.

The "Watches" view supports expressions. User can select any expression in the "Editor" window, click the right mouse button, select "New Watch..." item, and a "New Watch" dialog appears with selected expression:

New Watch dialog, Expression

Note that when expression was selected in the "Editor" window, a tooltip evaluation appeared. You can see it in the picture below. This feature is very similar to a "watch". The main difference is that "watches" are permanent, and they are shown in the "Watches" view:

Watches view shows expressions

Unfortunately "Watches" view is not very stable yet, and sometimes types are not shown - you can see "null" instead of "int" on this picture.

6. Sessions and Threads.

Multi session support is implemented. It means user can debug two or more projects in parallel in the same IDE. There is a special "Sessions" view to show which sessions are running now:

Sessions view, available Actions

Theoretically it is possible to debug a C/C++ project and and Java project in parallel in the same IDE, but they are using different debugging modules, and there could be some conflicts, so I would not recommend to do such things. Even if you debug two C/C++ projects in parallel in the same IDE, it is a very difficult and confusing task, because debugging windows do not show which session is current now (only "Sessions" view shows current session).
Unfortunately "Threads" view is always empty - threads are not supported in this release. Also there is no support for multiprocessing - if a program uses fork() to create child processes, there is no option to debug a child process.

7. Debugger Console.

This release of debugging module has a very powerful feature - direct dialog with "gdb" via "GDB Debugger Console". Unfortunately this is  "unfinished" feature, and I think a beginning user will not want to use this window because it shows the whole dialog between the debugging module and  "gdb", so it is hard to find important messages there. But for "gdb" experts this feature is priceless. At any moment I can type in a "gdb" command in "GDB Debugger Console", press Enter, and this command will be sent to "gdb". Obviously there is a risk that the debugging module will not understand a reply from "gdb" caused by manually sent command. Probably that's why this feature is hidden, and it is not easy to enable this console. I use the following way to enable "GDB Debugger Console":
- there is a directory "etc" in NetBeans installation tree, and it contains file "netbeans.conf"
- there is a line in netbeans.conf file, which defines "netbeans_default_options":
    netbeans_default_options="-J-Xms32m -J-Xmx128m -J-XX:PermSize=32m ..."
- I change the maximum memory limit (because 128 megabytes is usually not enough), and add option to show "GDB Debugger Console":
    netbeans_default_options="-J-Xms32m -J-Xmx328m -J-Dgdb.console.window=true -J-XX:PermSize=32m ..."

This option (-J-Dgdb.console.window=true) tells IDE to show "GDB Debugger Console" when a debugging session starts. You can see it on the picture below. In this example I set a conditional breakpoint at line 41 ("break if argc<3"), and the program stopped there:

GDB Debugger Console

Debugging module does not show a breakpoint icon on line 41, because I used CLI syntax, and because this breakpoint was not set from inside IDE. But, what is good, it did not break anything, and I can continue the debugging. NetBeans C/C++ Development Pack 5.5 debugging module is using GDB/MI interface to communicate with debugger "gdb", so it is probably better to type in gdb commands using GDB/MI syntax.
Even if you don't want to type in gdb commands, it makes sense to have "GDB Debugger Console" open, because in some cases it is not clear what is going on (for example, why a "Step Over" action does not change anything?), and in this case "GDB Debugger Console" is extremely helpful - it shows gdb commands and replies, which makes easy to understand the problem.

Unfortunately "GDB Debugger Console" is called "Debugger Console", and there is another "Debugger Console" window, so there could be some kind of confusion - too many "Debugger Console" windows:

Debugger Console (default)

This is probably another reason why "GDB Debugger Console" is hidden.

8. Integration with NetBeans Editor.

Integration with the NetBeans "Editor" is pretty much traditional. When a debugging session is active, and the program is stopped, the "Editor" shows:
  •   current source file
  •   current line ("green arrow" and "green background")
  •   breakpoint annotations ("red squares" and "red background")
  •   call stack lines ("gray triangle" and "gray background")
  •   tooltip evaluation of selected expression
Editor, Debugging Session is active

If there is no debugging session, only breakpoint annotations are shown in the "Editor".

9. Menu, Toolbar Buttons and Hot Keys.

Debugging Toolbar Buttons

There are 11 toolbar buttons, related to debugging:
  • Debug Main Project (F5)
  • Attach Debugger...
  • Finish Debugging Session (Shift+F5)
  • Pause
  • Continue (Ctrl+F5)
  • Step Over (F8)
  • Step Into (F7)
  • Step Out (Ctrl+F7)
  • Run to Cursor (F4)
  • Apply Code Changes
  • New Watch... (Ctrl+Shift+F7)

Three of them are not implemented in this release:
  • Attach Debugger...
  • Run to Cursor
  • Apply Code Changes
They are not removed from the toolbar, because they are used in Java debugging.

Also there are some problems with "Pause" on Cygwin/Windows. These problems do not affect Linux or Solaris. To implement this feature on Windows in Cygwin environment a dynamic library ("cnd.dll") is used, which implements a signal handler ("_CndSigHandler" function). When debugging is starting, this signal handler is instrumented into the program (using LD_PRELOAD method). Then the program is stopped in "main" function and this signal handler is activated. After that the execution begins, and if user pressed "Pause" button, a signal (SIGTSTP) is sent to the program. Signal handler catches this signal, and execution is stopped at a special breakpoint. After that a few single steps are used to get back to user's sources. And in some cases this algorithm does not work - "gdb" cannot get back to the user's sources, and "Call Stack" view shows that the program is stopped in "_CndSigHandler" function. This is a known problem and I hope it will be fixed in next release (IZ 90120).

Nikolay Molchanov

December 2006

Project Features

About this Project

CND was started in November 2009, is owned by DimaZh, and has 233 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm