Useing a debugger to find crashes
Author
Now I'm useing DevC++. Sometimes my program crashes and I spend days going through the program line by line untill I find the problem. I know that nowdays there are debugging programs/methods that let you find the point that the program crashed at much more easily. Can someone show me the way to do this? - A while ago someone mentioned the gdb but I couldn't understand how to use it.
Also, I need this to work as I'm running the program and giving it input.
Thanks.
I'm a visual studio user so I can't help you out with DevC++ but a debugger allows you to attach to a process and step through code line by line. It also allows you to attach to a crashed process and examine the call stack. This lets you see what the program was trying to do when it crashed. From there you can work backwards to find your bug.
Yeah I'm a VC user as well so can't help you of the IDE/debugger specifics, I have stumbled accross some nice looking frontends for gdb (can't remember where though sorry).
The main generic tools of debugging (and what a standard debugger will support) and what you will need to use to debug are as follows:-
BreakPoints - Select lines of code for the debugger to stop on.
Step/Step into/ Step Out of - The debugger gives you the abilty to step through code execution one item at a time, either at a source line level or a assembly instruction level, they also allow you to 'step into' functions and 'step out' of functions (i.e. you've gone into a function and realised you don't care so want to get back to the calling function).
Register Pane - Shows you the current state of the registers, Program counter, what exception occured. This is very useful i.e. on MIPs chips a0 is generally used for the t'this' pointer in C++, and ra contains the return address etc, so even if it dies in release mode you can still work out what happened.
Callstack - Shows the tree list of functions called at this time, so you can see what called what.
Watch Window - Add variables to this that you want to see the values of, i.e. globals, counter etc.
Local Variables - What are the local variables of the current function and what are there values.
Memory Window - Give it a pointer and it'll show you the raw memory at this location (usually giving you the abilty to view it as char, float, ints etc).
Source Window/Assembly Window - Source code view of current Program counter location (normally with the ability to view the asm instructions as well).
Kernel/Thread View - Ability to see the current state of threads and swap between debugging each one.
Pen and Paper - The best tools ever :)
Disclaimer:-
The above list is neither complete nor writtern well or with any thoughtfullness, however they are the generally tools used for debugging.
And remember debugging is a very important skill....I've seen a work mate debug a doubley-linked list in a memory manager with his finger in a memory window...finger moving around the screen following the links :)
Paul
The main generic tools of debugging (and what a standard debugger will support) and what you will need to use to debug are as follows:-
BreakPoints - Select lines of code for the debugger to stop on.
Step/Step into/ Step Out of - The debugger gives you the abilty to step through code execution one item at a time, either at a source line level or a assembly instruction level, they also allow you to 'step into' functions and 'step out' of functions (i.e. you've gone into a function and realised you don't care so want to get back to the calling function).
Register Pane - Shows you the current state of the registers, Program counter, what exception occured. This is very useful i.e. on MIPs chips a0 is generally used for the t'this' pointer in C++, and ra contains the return address etc, so even if it dies in release mode you can still work out what happened.
Callstack - Shows the tree list of functions called at this time, so you can see what called what.
Watch Window - Add variables to this that you want to see the values of, i.e. globals, counter etc.
Local Variables - What are the local variables of the current function and what are there values.
Memory Window - Give it a pointer and it'll show you the raw memory at this location (usually giving you the abilty to view it as char, float, ints etc).
Source Window/Assembly Window - Source code view of current Program counter location (normally with the ability to view the asm instructions as well).
Kernel/Thread View - Ability to see the current state of threads and swap between debugging each one.
Pen and Paper - The best tools ever :)
Disclaimer:-
The above list is neither complete nor writtern well or with any thoughtfullness, however they are the generally tools used for debugging.
And remember debugging is a very important skill....I've seen a work mate debug a doubley-linked list in a memory manager with his finger in a memory window...finger moving around the screen following the links :)
Paul
Author
Thanks, the main thing that I want to learn how to do is to use the gdb or anyother DB tool to find out were my program crashes. Since my program only crashes late in the program and with specific input it is important that I can use the program normally (with the db on) and then get output from the db when it crashes.
Thanks!!
Thanks!!
In that case google is your friend 'gdb tutorial' shows loads of hits to look at,
I always step through my code when I write it, so I'm basically debugging it before I know it has any bugs in it:)
Paul
I always step through my code when I write it, so I'm basically debugging it before I know it has any bugs in it:)
Paul
I'm assuming you're on some sort of UNIX.
First, make sure you always get core dumps from crashes. Then you can do post-mortem debugging. Typically, you'll do something like "limit coredumpsize 2000" (depending on your specific shell and OS).
Then, when your program has crashed, and you get a file called something like "core.1234" in the working directory (1234 is the PID), you can do:
This will show a bunch of lines about loading shared modules, and then get you a command prompt. Type "bt" and you will get a stack trace of the call chain up to the point where you crashed. You can use "f N" where N is a stack trace number to select that stack frame as context, and then type "print foobar" to see the value of the variable foobar at that point.
If you want to debug "live" then you start gdb without a core file:
Then set breakpoints at file and line of interest using "br file.cpp:1234". Start the program using "run" (you can give command line arguments after the run command).
First, make sure you always get core dumps from crashes. Then you can do post-mortem debugging. Typically, you'll do something like "limit coredumpsize 2000" (depending on your specific shell and OS).
Then, when your program has crashed, and you get a file called something like "core.1234" in the working directory (1234 is the PID), you can do:
gdb path/to/program core.1234This will show a bunch of lines about loading shared modules, and then get you a command prompt. Type "bt" and you will get a stack trace of the call chain up to the point where you crashed. You can use "f N" where N is a stack trace number to select that stack frame as context, and then type "print foobar" to see the value of the variable foobar at that point.
If you want to debug "live" then you start gdb without a core file:
gdb path/to/programThen set breakpoints at file and line of interest using "br file.cpp:1234". Start the program using "run" (you can give command line arguments after the run command).
Author
My main problem is that I have no idea how to give commands to the gdb in Dev.
Does the Debugger (blue check) have to be running and do I have to change the db option to yes in the project options for the gdb to work?
And were do I type the commands - in that small box on the bottom?
Thanks.
Does the Debugger (blue check) have to be running and do I have to change the db option to yes in the project options for the gdb to work?
And were do I type the commands - in that small box on the bottom?
Thanks.
Use insight, it is packkage which helps you. It is own program. It can do simply everything as above said. Dev-c++ debugger is crab and is not yet ready. I use it only trace where my program goes.
Be aware that the simple fact of using a debugger may well influence your program flow in such a way that it either no longer crashes or crashes somewhere else.
This is especially true if the crashes happen in time-critical and/or multithreaded code, but it can happen everywhere.
I've had more than one occasion in Assembler where adding a single nop instruction would either cause or stop crashes or corrupted output.
Similar things happen all the time in other languages when adding logging statements. Remove the logging and it crashes, add it back in and it works fine...
This is especially true if the crashes happen in time-critical and/or multithreaded code, but it can happen everywhere.
I've had more than one occasion in Assembler where adding a single nop instruction would either cause or stop crashes or corrupted output.
Similar things happen all the time in other languages when adding logging statements. Remove the logging and it crashes, add it back in and it works fine...
Author
Thanks,
In the main gdb page it says:
"Invoke GDB by running the program gdb. Once started, GDB reads commands from the terminal until you tell it to exit. "
How do I run the program gdb?
Were do I type commands as my program is running?
Thanks.
In the main gdb page it says:
"Invoke GDB by running the program gdb. Once started, GDB reads commands from the terminal until you tell it to exit. "
How do I run the program gdb?
Were do I type commands as my program is running?
Thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
