5 ms·
Yep, two other more 'deterministic' strategies should have caught this: interactive debugging should have showed that the memory is set to zero immediately afte
by lgeek 13y ago
Yep, two other more 'deterministic' strategies should have caught this: interactive debugging should have showed that the memory is set to zero immediately after loading, not while running; and inspecting the symbol table could have revealed that only data after a fixed offset is corrupt.
- pja 13y agoIt's much easier to realise the perfect debugging strategy with the benefit of hindsight!
- shabble 13y agoIf only that was how Time-travelling Debuggers[1][2] worked! [1] http://chrononsystems.com/products/chronon-time-travelling-debugger http://chrononsystems.com/products/chronon-time-travelling-d... [2] https://www.gnu.org/software/gdb/news/reversible.html https://www.gnu.org/software/gdb/news/reversible.html
- pja 13y agoTime travelling debuggers are awesome, but they still can't compete with already knowing the cause of the bug when trying to find the shortest path from bug to cause!
- greenyoda 13y agoNo, you don't need hindsight to figure this out. It should be easy to figure out in advance which of these strategies is likely to be more effective in solving a problem: (1) Go into the debugger and trace how the system got to the bad state it was in. (2) Randomly change stuff and see if it fixes the problem. After doing (1), you understand exactly what your code is doing and why. After doing (2), you may not even understand what the problem really was, or why it got fixed, or whether it's really fixed or just doesn't happen any more in this particular situation. I've seen people debug using strategy (2), and when they give up and ask for help, stopping, thinking a while and employing strategy (1) will usually find the problem.