Differences between version 6 and revision by previous author of AdvancedDebuggingHints.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 6 | Last edited on Friday, September 10, 2004 10:41:26 pm | by StuartYeates | Revert |
| Older page: | version 2 | Last edited on Friday, September 10, 2004 11:45:42 am | by CraigBox | Revert |
@@ -1,5 +1,5 @@
-This page is useful for advanced debugging tricks that we've found over the years, each hint has a description of the problem we were trying to face, and how we solved it.
+This page is useful for advanced debugging tricks that we've found over the years, each hint has a description of the problem we were trying to face, and how we solved it. If these tools are way over your head, try looking at the DeBugging page instead, it covers a lot of the more simple tools
.
!!!Ringlog
We once had a bug in ircu where it would crash in one piece of code, something had obviously been corrupted, but this code was obviously not the cause of the bug, but a value was being set incorrectly just before hand.
@@ -17,6 +17,17 @@
!!!valgrind
valgrind lets you set r/w permissions per byte. In the above issues you can flag a byte as being r/o and let valgrind raise an assertion when that memory is written.
------
-CategoryProgramming
+!!!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
+
+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.
+
+
+
----
+CategorySoftwareEngineeringTools
