[size="4"]Hi!
Is there any debugging tools for Linux/C++ programs(Like setting a break point and examining the variable values in VC++)? How to debug a Linux/C++ program? I'm using Red Hat Linux 5.
Debugging with Linux
Straight GDB if you're into terminal stuff, otherwise most of the open source IDEs will have an interface for it, for example Code::Blocks works great.
Learn GDB. It's immensely powerful... it's also scriptable, so you can write your own tools for things.
Easy intro;
gdb YOURBINARY
"gdb -p PID" attaches GDB to an already running process.
When in command mode;
b SOURCEFILE:LINENUM -- put a breakpoint in
run <arguments> -- run program with these args.
When it stops, or you CTRL-C it, you'll get a prompt.
"list" shows you the current code
"where" shows you the stack frames
"frame N" selects a stack frame
"print EXPR" evaluates and prints an expression.
"cont" continues the run.
It's fairly trivial to do things such as "every time through here see if X is true", "at this place stop if X was true and also now Y is as well". Command lists can be used to insert "correct" values into variables so runs can continue... In the limit, GDB has an API accessible to Python.
GDB will also let you record a run and step both forward and backwards through it.
Another useful tool is "strace". "strace YOURBINARY YOURARGS" which will dump all the system calls (with return codes). "strace -p PID" does it to something already running. This is useful for answering those "what IS it doing at the moment" type questions -- hang a strace on it and you can see all the reads/writes/epolls etc.
valgrind YOURBINARY YOURARGS will run your app looking for overflows, unallocated pointers and so on.
Easy intro;
gdb YOURBINARY
"gdb -p PID" attaches GDB to an already running process.
When in command mode;
b SOURCEFILE:LINENUM -- put a breakpoint in
run <arguments> -- run program with these args.
When it stops, or you CTRL-C it, you'll get a prompt.
"list" shows you the current code
"where" shows you the stack frames
"frame N" selects a stack frame
"print EXPR" evaluates and prints an expression.
"cont" continues the run.
It's fairly trivial to do things such as "every time through here see if X is true", "at this place stop if X was true and also now Y is as well". Command lists can be used to insert "correct" values into variables so runs can continue... In the limit, GDB has an API accessible to Python.
GDB will also let you record a run and step both forward and backwards through it.
Another useful tool is "strace". "strace YOURBINARY YOURARGS" which will dump all the system calls (with return codes). "strace -p PID" does it to something already running. This is useful for answering those "what IS it doing at the moment" type questions -- hang a strace on it and you can see all the reads/writes/epolls etc.
valgrind YOURBINARY YOURARGS will run your app looking for overflows, unallocated pointers and so on.
I prefer kdbg, which is a graphical front-end to gdb like ddd. I was introduced to ddd nearly a decade ago and I recently gave it yet another try, but I still don't like that tool. The interface is just...cumbersome and messy. kdbg is more intuitive IMO and is extremely easy to pick up and use. I never really bothered to learn gdb straight up because I don't like doing all my debugging in a terminal window. There's too much information you have to keep track of, and a graphical interface really helps to manage that info.
Maybe I'm foolish, but I find it much less cumbersome to just sprinkle in printf's and perrors to watch what's going on, rather than mess with gdb.
I commend you if you have the fortitude to learn gdb; most of my unix programming has been stuff for classes where I've only got a couple of days to churn out a largish assignment, where I already have to spend half my time teaching myself sockets, or pthreads, or what have you, so it's usually a question of spending the time learning yet another tool, or getting the work done. Hence, I'm still using the command-line, geany, make, and svn, rather than any of the fancier things. Your mileage may vary.
Valgrind with --leak-check=full is really a godsend, especially if you're working in C, for pinpointing where things are breaking, and of course, for cleaning up memory leaks.
Also, as I've found out recently, its good for figuring out if you have SIGPIPEs from trying to send to a bad socket mysteriously killing your programs.
I commend you if you have the fortitude to learn gdb; most of my unix programming has been stuff for classes where I've only got a couple of days to churn out a largish assignment, where I already have to spend half my time teaching myself sockets, or pthreads, or what have you, so it's usually a question of spending the time learning yet another tool, or getting the work done. Hence, I'm still using the command-line, geany, make, and svn, rather than any of the fancier things. Your mileage may vary.
Valgrind with --leak-check=full is really a godsend, especially if you're working in C, for pinpointing where things are breaking, and of course, for cleaning up memory leaks.
Also, as I've found out recently, its good for figuring out if you have SIGPIPEs from trying to send to a bad socket mysteriously killing your programs.
Maybe I'm foolish, but I find it much less cumbersome to just sprinkle in printf's and perrors to watch what's going on, rather than mess with gdb.
That works fine if you're working with simple applications and programming assignments. I did the same thing when I was in college and never really touched a debugger. But when you are working with very large applications (like games) it becomes near impossible to do that, especially when you have update loops and draw loops that are being executed over and over and over. Being able to set a breakpoint, examine the state of all variables in the current context where execution has halted, and easily finding out the exact line where a segfault occurred save you hours upon hours of debugging time, where printfs would just be extremely tedious and inefficient. Not to mention that large applications take a much longer time to compile.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
