Differences between version 7 and revision by previous author of AdvancedDebuggingHints.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Monday, September 13, 2004 9:08:31 am | by SamJansen | Revert |
| Older page: | version 6 | Last edited on Friday, September 10, 2004 10:41:26 pm | by StuartYeates | Revert |
@@ -21,13 +21,27 @@
!!!Statistical Profiling
We had a program that was running fine one day, then afew days later was being dog slow. We wanted to quickly and easily figure out why the program was so slow. By attaching gdb to it, stopping it at random, and looking at where the program was, and then continuing it. If you do this about 10x, you'll get a feel for what functions it's sitting in. The probability of stopping it anywhere says that you're more likely to stop it in a function that's taking most of the CPU.
-!!!Snapshotting state
+!!!Snapshotting State
Ever wanted to know what the state of a program is, without having to stop it? This is particularly important for long running programs. Add some code (or use gdb) to make it fork() and have the child dump core. The parent can even wait for the child and rename the core file based on the time, or what it was doing. This is a handy way for having an "almost" assertion. An assertion that fires, but doesn't kill the program (eg, because you know how to recover from it, but it shouldn't be occuring).
Beware that dumping core is often a slow and intensive process and may impact performance of your system, particularly disk-poor systems.
+!!!Reproducing Program State
+
+Sometimes to reach a part of the programs execution and debug it in gdb it is not as simple as putting a breakpoint in a single function. Using a ''.gdbinit'' file in the directory in which you are debugging the program is useful. The ''.gdbinit'' file can contain the commands that you type into gdb. Example:
+
+ set args file.input
+ break do_stuff
+ display g_my_stuff
+ run
+ continue 2
+ tbreak set_stuff
+ continue
+ until 192
+
+This runs some theoretical program with ''file.input'' as an argument, breaks in ''do_stuff'', displays ''g_my_stuff'' every time the program stops, continues twice past the ''do_stuff'' breakpoint, sets a temporary breakpoint in ''set_stuff'', continues till it hits this breakpoint, then continues until line 192. All of this is automated when you type ''gdb programname'' in the directory the ''.gdbinit'' resides in.
----
CategorySoftwareEngineeringTools
