20 minutes guide to GDB

First thing to know is in order to run gdb you need to have things compiled with debug symbols: –g option for the compiler.

Then call the program with gdb and the parameter –args. If the program has arguments, use them too.

gdb --args your_program --arg1 --arg2.

Remember to call ./tools/imppy.sh first if you are using IMP in the build directory. That is, do

./tools/imppy.sh gdb python modules/core/test/test_rigid.py

And now a couple of very basic things that would work 75% of the time

  1. Break: To stop the code at a given line or function:

  2. break 150

  3. b filename:linenum

  4. break my_function

  5. When using IMP, you probably what to break when an error occurs. To do this, do
  6. b IMP::handle_error

  7. run: Runs the program up to the first break. Use r

  8. Continue: Runs the program to the next break. Use c

  9. Next: Runs the next line of code. Use n

  10. Stepping: If you are at a given line, the next instruction is run. But if a function is called, it will enter into the function.

  11. Print variables: Use p eg p list.size()

  12. End program: Use kill

  13. Bactrack: To see the functions called up to a given crash. Use bt. To walk up and down the stack use u and d.

  14. Quit gdb: Use q or ^d.

So lets go with an example. Suppose this function

double function1(int arg1,int arg2) {
  int x=0;
  std::cout << x ;
  double y=arg1+arg2;
  x=function2(y);
  double v = x*3.145;
  double z=function3(v);
  return z;
}


gdb –args my_program –I file.

b function1 // I suspect a problem with that function

r // run the program. It stops at that function call.

p arg1 // Print 1st arg.

p arg2 // Print 2nd arg.

s // The arguments seem to be ok. I step into the function. I keep doing that until something interesting happens. In the meantime print variables, etc

n // the function1 calls function2(), but I skip it. I think it is fine.

p x // I print x. Seems fine too.

n // next line

n // I try to skip function3(). Program crashes.

bt // I see what functions were called. Here the output is variable, but you should get an idea of which function was called the last before crashing. So function3() seems to be the problem.

kill // I stop the execution of the program.

b function3 // break at function3

r // run again. This time I will have to step into function3 and see what is going on ... etc.

That's it. With this you should be fine until something more complicated requests to look at the gdb manual: http://www.gnu.org/software/gdb/documentation/

IMP: 20 minutes guide to GDB (last edited 2011-09-19 23:18:12 by DanielRussel)