Get ccdebug at Fast, secure and Free Open Source software downloads

ccdebug - a graphical gdb debugger frontend

Debug tips

First of all, compile with debug information (switch -g). Don't use optimization without need, debugging might become confusing. Also note that gdb/mi is not compatible with all gdb/console commands. This means that .gdbinit files in your home directory or the application directory may cause problems if they contain incompatible commands.

If possible, you should use at least gdb 6.8. Beginning with this version gdb/mi supports setting (pending) breakpoints in shared libraries not loaded yet, and more reliable breakpoints in constructors.

Source files

If some or all binaries have been compiled on another machine within another source file directory tree, then gdb and ccdebug cannot find the source files. Starting with version 6.7 you may use the gdb command "set substitute-path" to define a source path substitution rule.

If there are source files with identical name (from different shared libraries), it may be difficult for gdb and ccdebug to load the correct file. In that case the best solution is to rename a file and recompile the shared library. If this isn't feasible, you may try to assign a higher priority to a source file by clicking onto the "Prefer" button in the source files dialog (Alt-Ctl-F).

Breakpoints in dynamically loaded shared libraries

Breakpoint data are stored in the XML-file .ccdebugDbg in your home directory. When an application is started again in ccdebug, then ccdebug tries to set the breakpoints. This will fail for breakpoints in shared libraries, as long as the library is not loaded yet. However, gdb versions newer than gdb6.8 keep a list of pending breakpoints and try to set them when a shared library was loaded.
Hint: Use absolute file pathnames to set breakpoints. To achieve this open the source file with the file dialog (Ctl-O), locate the line and press F9.

For older gdb versions there is some automatism in ccdebug: ccdebug retries to set the breakpoints every time gdb stops.

Source files from shared libraries are only available when the shared library has been loaded. To see the files in the source files dialog (Alt-Ctl-F), the button "Update" must be pressed. Header files (*.h) are only listed when the "Show header files" check is set. To locate some shared library source file you might set a breakpoint at the position where the shared library gets loaded.
Gdb normally loads the shared library symbols automatically. In special circumstances this may be done explicitely with the gdb command "share" (Alt-Ctl-G).

Customizing signal handling

Signal handling may be specified in the "Signals" dialog. To completely ignore a signal you may uncheck "Stop", "Print" and "Pass". To completely disable a signal each time the session is started you may enter a line "handle <sigName>" in the "Pragma" text field of the "Session" dialog, where <sigName> is the signal name (for instance SIG32).

Displaying QStrings and user defined data types in the popup/tooltip window

To display user defined data types in a specific way in the popup window, add the function printUsrDefType() to your ~/.gdbinit file, and insert the desired printf() statements. This function gets called from ccdebug when the cursor is above a variable name in the editor window. $arg0 is the data type name, $arg1 is the expression to evaluate. To get started you might simply copy the ~/.gdbinit from the ccdebug directory to your home directory (if this wasn't done during installation).

#printUsrDefType. arg0 is the typeName, arg1 is the expr//
define printUsrDefType
	__strcmp $arg0 "CMyType1"
	if $match
		printf "printUsrDefType(CMyType1) says: %d\n", $arg1.val
	__strcmp $arg0 "CMyType2"
	if $match
		printf "printUsrDefType(CMyType2) says: %d\n", $arg1.val
	#ToDo for your types: Add __strcmp statements and corresponding if-end blocks doing the printf()
For this to work the string compare function __strcmp() also must be added to your ~/.gdbinit file:
#From Ira L. Ruben, gdbinit-MacsBug-without-plugin//
define __strcmp
    set $__s1 = (unsigned char*)($arg0)
    set $__s2 = (unsigned char*)($arg1)
    set $match = 1
    set $__c1 = *((unsigned char*)$__s1)++
    while ($match && $__c1)
    	set $__c2 = *((unsigned char*)$__s2)++
		if ($__c1 == $__c2)
			set $__c1 = *((unsigned char*)$__s1)++
			set $match = 0
    set $match &= (*(unsigned char*)$__s2 == 0)
If ccdebug doesn't find the printUsrDefType function, in the case of QStrings it then tries to call pqs, which should print the Qt4 (or Qt3) QString.
ccdebug contains some internal handling for some STL data types (string, vector, list,...). To disable this and to use the printUsrDefType function please set the variable useInternalTooltipFunctions in the file ~/.ccdebugDbg to "0".

C++ Exception handling

To interrupt program execution when a C++ exception gets thrown enter "catch throw" in the gdb window (Alt-Ctl-G).
To interrupt program execution when a C++ exception gets catched enter "catch catch" in the gdb window (Alt-Ctl-G).

Incompatible Qt versions for application and ccdebug

If your application is linked against another Qt version than ccdebug, then depending on the environment variable LD_LIBRARY_PATH ccdebug or the application might not start. Simply passing the correct LD_LIBRARY_PATH to gdb doesn't solve the problem. A workaround is to start the application from the command line and to "Attach" ccdebug to the running application.
A better solution is to specify a shell script as "gdb" in the "Session" dialog's "Pragma" field by adding a line "gdb <PathnameOfScript>". The script should set LD_LIBRARY_PATH and other variables and then start gdb, for example

#Description: Sets environment for program to debug and starts gdb.
export LD_LIBRARY_PATH=.:/extraQt/lib:
<PathToGdb>/gdb "$@"

Debugging ccdebug with ccdebug

Although not very useful, debugging ccdebug with ccdebug is possible in conjunction with at least gdb6.8 due to the possibility to set "pending" breakpoints in shared libraries. To have several active instances of ccdebug may be confusing, and it is useful to change the background color of one instance (by pressing Esc-#).

Remote debugging

Specify an "Executable" (with debug information) in the "Debug Session" dialog as usual. This executable normally will be somewhere on the (local) client machine and contains the debug information. Enter the target data in the field "Remote" in the format hostname:portnumber, where portnumber is the number passed as argument to gdbserver on the target. For details please consult the gdbserver man page.
To interrupt a running program, press Ctl-C on the remote machine in the console gdbserver is running in. See also the file readme.txt.