Author : LUPG
Page : << Previous 2
process executes exactly the same program whose path we gave to gdb (not a copy of the file. it must be the exact same file that the process runs), it'll attach to the program, pause its execution, and will let us continue debugging it as if we started the program from inside the debugger. Doing a "where" right when we get gdb's prompt will show us the stack trace of the process, and we can continue from there. Once we exit the debugger, It will detach itself from the process, and the process will continue execution from where we left it.
Debugging A Crashed Program
One of the problems about debugging programs, has to do with Murphy's law: A program will crash when least expected. This phrase just means that after you take the program out as production code, it will crash. And the bugs won't necessarily be easy to reproduce. Luckily, there is some aid for us, in the image of "core files".
A core file contains the memory image of a process, and (assuming the program within the process contains debug info) its stack trace, contents of variables, and so on. A program is normally set to generate a core file containing its memory image when it crashes due to signals such as SEGV or BUS. Provided that the shell invoking the program was not set to limit the size of this core file, we will find this file in the working directory of the process (either the directory from which it was started, or the directory it last switched to using the chdir system call).
Once we get such a core file, we can look at it by issuing the following command:
gdb /path/to/program/debug_me core
This assumes the program was launched using this path, and the core file is in the current directory. If it is not, we can give the path to the core file. When we get the debugger's prompt (assuming the core file was successfully read), we can issue commands such as "print", "where" or "frame X". We can not issue commands that imply execution (such as "next", or the invocation of function calls). In some situations, we will be able to see what caused the crash.
One should note that if the program crashed due to invalid memory address access, this will imply that the memory of the program was corrupt, and thus that the core file is corrupt as well, and thus contains bad memory contents, invalid stack frames, etc. Thus, we should see the core file's contents as one possible past, out of many probable pasts (this makes core file analysis rather similar to quantum theory. almost).
Getting More Info About Debugging
It is now probably time to go play around with your programs and your debugger. It is suggested to try "help" inside gdb, to learn more about its commands. Especially the "dir" command, that enables debugging programs whose source code is split over several directories.
Once you feel that gdb is too limiting, you can try out any of various graphical debuggers. Try to check if you have "xxgdb" installed - this is a graphical interface running on top of gdb. If you find it too ugly, you can try out "ddd". Its main advantage over xxgdb is that it allows you to graphically view the contents of pointers, linked lists and other complex data structures. It might not be installed on your system, and thus you'll need to download it from the network.
If you're running on a SunOs or Solaris environment, there is a program named "gcore", that allows taking the core of a running process, without stopping it. This is useful if the process is running in an infinite loop, and you want to take a core file to keep aside, or you want to debug a running process without interrupting it for too long.
Page : << Previous 2