Next Previous Contents

12. A belső nyomkövető

12.1 Setup

The default setup for KDevelop is to use the internal debugger. You can change this under Options select the "KDevelop setup" menu item, and then the Debugger tab.

Click on "Use external debugger" if you wish to use a different debugger and enter the name of the debugger to use. See your debuggers documentation on how to run it.

Selecting the internal debugger enables an additional set of options you can choose from:

12.2 Using the internal debugger

Changes made in the tree and output view window

If you choose the internal debugger, four tabs are added to your tree and output view windows.

On the tree view window

On the output view window

Changes made in the Debug menu and on the panel

On the panel

Two normal and two dropdown buttons to control the debugger functions will be accessible as soon as you start the debugger.

In the Debug menu

When you start debugging, ten items to control the debugger will be enabled.

Available functions:

Details

Breakpoints

Breakpoints can be set against source lines in a file (referred to as breakpoints) or on variables in the source (referred to as watchpoints). Both types of breakpoints can be set at anytime, however watchpoints on local variables only have meaning in the variables local scope. Watchpoints have more meaning when you are dealing with global variables.

Set/Unset breakpoints

Simple one click set/unset. Click on the "icon" border to the left of the text in the editor at the line you want the breakpoint. Click again on this line to unset the breakpoint.

Alternative beakpoint manipulating via menus

By right clicking on a breakpoint in the breakpoint list or on a breakpoint in the editors icon border you will get a menu of breakpoint options. This allows you to remove this breakpoint, clear all breakpoints, or edit the breakpoint.

Editing breakpoints

Use the above menu to display the edit breakpoint dialog. This contains the following fields :

  1. Conditional: Enter the condition that must be met before gdb will interrupt the program execution.
  2. Ignore count: How many times you want the code to past through this breakpoint before gdb interrupts the program execution.
  3. Enable: When enabled gdb will break at this breakpoint. When disabled gdb will not break here.

Clear all breakpoints

Removes all the breakpoints for this program.

Set/Unset watchpoints

In the VAR view click with the Right Mouse button on a variable. A popup menu will be displayed allowing you to set a watchpoint on the local variable. This functionality is limited to the scope that the local variable is in. As the variable goes out of scope the program breaks and the watchpoint is deleted.

WARNING: This is known to be problematic, so use caution when setting watchpoints on local variables.

The watchpoint can also be set by a right mouse click on a previously entered watch variable, and selecting "toggle watchpoint"

Set/Unset Watch variables

At the bottom of the VAR view there is the "Watch" field where you can enter the variable name you wish to see display in the watch list. Enter the variable name and type "enter" or click on the "Add" button alongside the field. Right Mouse clicking on the watch variable in the treeview will bring up a menu so that you can remove the variable from the list.

You can also enter a watch variable by right mouse clicking on a variable name in the editor window. This displays a popup menu with "watch: variable name" on it.

Changing variable values

This is done via the watch variable. If you have a variable "test" then to set "test" to 5 type "test=5" in the watch field and add it to the list. Note that "test" will be set to "5" EVERY time the program stops at a breakpoint, so once you have set the variable, usually you should remove the item from the watch view.

12.3 The floating toolbar

The floating toolbar is a feature of the internal debugger, which greatly improves your comfort in debugging GUI applications. The toolbar is either on top of all windows displayed, or docked into the panel. When docked you can run your code by clicking on the docked icon. The function this performs is the "step over" function. Right clicking on the docked item allows you to restore the toolbar and optionally place focus on kdevelop.

Besides the functions available from the Debug Menu, the floating toolbar offers two additional functions:

When gdb interrupts the program, probably because a breakpoint has been triggered, we highlight the "Set focus on kdevelop". We do not automatically switch focus to kdevelop so that you can view the application window at this point. Click on the "set focus" button to switch to kdevelop or press a button on the toolbar to perform your selected function.

12.4 Shared libraries and breakpoints

Shared libraries and breakpoints have a problem that has a reasonable solution. The problem is that gdb will not accept breakpoints in source that is in a shared library which has not yet been opened but will be opened via a dlopen.

The solution is to get gdb to tell us when a shared library has been opened. We do so by setting "stop-on 1". This means that when the user sets a breakpoint, we flag this breakpoint as pending, try to set the breakpoint and if gdb says it succeeded then flag it as active. If gdb is not successful then we leave the breakpoint as pending. The next instruction will always be "continue" .

This is known as "lazy breakpoints"

You have to be careful, though. If you inadvertantly set a breakpoint in a file that is really outside the program, that is it's neither part of the program nor of any shared library inside the project, then this breakpoint will always be pending. There's nothing you can do about that, because it might be in a shared library.

Now here's the problem with this. If the user "step"s over code that contains a library dlopen, then it isn't predictable what will happen. The dlopen will be catched by gdb, thus the code will stop. Now there are two possibilities, either there are pending breakpoints, then they will be marked as active and "continue" will lead to there. Or there aren't any pending breakpoints in this frame stack. Then the program will "continue" until it waits for input or it may lead us straight to the end, none of which is what we expected. In this situation, I do not do a continue but leave it stopped with the status line reflecting the stopped state. The frame stack is in the routine that caused the stop.

There isn't any way around this, but I could alleviate the problem somewhat by only doing a "set stop-on 1" when we have pending breakpoints.


Next Previous Contents