| For really big programs you can't use valgrind; valgrind causes significant performance hit and the system often starts to choke under the the memory load. Also GDB really alters the timing of things, so it is bad at timing/multithreading bugs. Mostly what helps is working through the logs & traces / following through the code along as you pass through the traces; Use a needle and a steady hand ;-) i guess that's what they should practice in school as part of learning the trade. On the other hand its a trade off - school needs to teach the general principles of programming, with regards to debugging it is hard to distill universally applicable principles; it all depends on what you are doing. Here is my take: - unit testing is cool, it allows to catch problems in isolation; so it would be useful to teach this as a discipline - for most GUI programs and application logic the debugger is really helpful - traces and log analysis as mentioned earlier as the last resort Also they should teach how to formulate the problem, analyse problem source and ways of fixing a defect; here you have to understand the trade offs: when to choose a local fix, when is a local fix no longer appropriate; how to quickly test a fix - so that it does not break the system in any way. If i remember correctly then some of that they do teach in software engineering courses. |
Adding logging also changes timing. Those aren't just NOPs you're throwing in. Also, changing timing isn't always a bad thing. Sometimes you can get a bug from a race condition to happen more often with the debugger.