Quick Navigation Bar
make and makefiles :: debugging techniques :: creating libraries
[ toc | forums ]

Note: If the document URL does not begin with https://randu.org/tutorials/c/ then you are viewing a copy. Please direct your browser to the correct location for the most recent version.

Debugging Techniques

Now that we have learned the basics of Makefiles, we can now look into debugging our code in conjunction with Makefiles.
As an introduction we will be using three debugging techniques:
1. Non-interactive
2. GNU gdb
3. dbx

Debugging Techniques :: Non-interactive

You can debug your code by placing #ifdef DEBUG and corresponding #endif statements around debug code. For example:
```
#ifdef DEBUG
  PRINTF(("Variables Currently Contain: %d, %f, %s\n", *pi, *pf[1], str));
#endif
```
You can specify a DEBUG define at compile time by issuing gcc with the -DDEBUG command option.
Note: This can be even further simplified into a single command called DPRINTF, so you don't even have to write the #ifdef #endif directives! How? Look at the Programming Tips and Tricks section (Quick Debugging Statements).

Debugging Techniques :: GNU gdb

gdb is a powerful program in tracking down Segmentation Faults and Core Dumps. It can be used for a variety of debugging purposes though.
First thing you must do is compile with the -g option and without any optimization (i.e. no -O2 flag).
Once you do that, you can run gdb <exe>. where <exe> is the name of the executable.
gdb should load with the executable to run on. Now you can create breakpoints where you want the the execution to stop. This can be specified with the line number in the corresponding c source file. For example: break 376 would instruct gdb to stop at line 376.
You can now run the program by issuing the run command. If your program requires command-line options or parameters, you can specify them with the run command. For example: run 4 -s Doc! where 4, -s, Doc! are the parameters.
The program should run until the breakpoint or exit on a failure. If it fails before the breakpoint you need to re-examine where you should specify the break. Repeat the breakpoint step and rerun. If your program stops and shows you the breakpoint line, then you can step into the function.
To step into the function use the step command. NOTE: Do not step into system library calls (e.g. printf). You can use the command next over these types of calls or over local function calls you don't wish to step into. You can repeat the last command by simply pressing enter.
You can use the continue command to tell gdb to continue executing until the next breakpoint or it finishes the program.
If you want to peek at variables, you can issue the print command on the variable. For example: print mystruct->data.
You can also set variables using the set command. For example: set mystruct->data = 42.
The ptype command can tell you what type a particular variable is.
The commands instruction tells gdb to set a particular number of commands and to report them to you. For example, commands 1 will allow you to enter in a variable number of other commands (one per line, end it with "end"), and will report those commands to you once breakpoint 1 is hit.
The clear command tells gdb to clear a specified breakpoint.
The list command can tell you where you are at in the particular code block.
You can specify breakpoints not only with lines but with function names.
For more information on other commands, you can issue the help command inside gdb.

Debugging Techniques :: dbx

dbx is a multi-threaded program debugger. This program is great for tracking down memory leaks. dbx is not found on linux machines (it can be found on Solaris or other *NIX machines).
Run dbx with the executable like gdb. Now you can set arguments with runargs.
After doing that, issue the check -memuse command. This will check for memory use. If you want to also check for access violations, you can use the check -all command.
Run the program using the run command. If you get any access violations or memory leaks, dbx will report them to you.
Run the help command if you need to understand other commands or similar gdb commands.

Debugging Techniques :: Other Debuggers

With Gnome 1.4, there is a program called MemProf. It is a memory profiler that can detect leaks. Although I have not personally used it, it could be a great graphical tool to use in finding those nasty memory leaks!
strace is another program that can trace the program. Although the output is much harder to parse than the other programs, this can be very useful in tracking down problems with your code.

Notice: Please do not replicate or copy these pages and host them elsewhere. This is to ensure that the latest version can always be found here.

Disclaimer: The document author has published these pages with the hope that it may be useful to others. However, the document author does not guarantee that all information contained on these webpages are correct or accurate. There is no warranty, expressed or implied, of merchantability or fitness for any purpose. The author does not assume any liability or responsibility for the use of the information contained on these webpages.

If you see an error, please send an email to the address below indicating the error. Your feedback is greatly appreciated and will help to continually improve these pages.