| I use debuggers (GDB) exclusively in batch mode. It allows for a very methodical debugging approach: 1 Formulate a Hypothesis 2 Determine what data you need for verification 3 Instrument code using gdb break commands, to hook function calls, sys-calls, signals, state-changes, etc. and print debugging information (variables, stack traces, timings) to a log file. 4 Then run an automated or manual test, of the failure you are debugging. 5 Then STOP data collection. Kill the process. Shut down the debugger. 6 Perform forensics on the log file. 7 Validate/Discard the hypothesis. With this allows you reason reliably about the computational process: - Why did I see this log line before this one? - Why was this variable NULL here, but not in here. You don't need to do that while you are in debugging session. You can take your time. You can seek back and forth in the file.
It's like dissecting a dead animal, not chasing a fly. In addition, you can share concise information with your colleagues: - This is the instrumentation - This is the action I performed - This is the output And ask concise questions, that people might be able to answer: > I expected XYZ in long line 25 to be ABC, but it was FGH. Why is this? |