Share the experience of my debug
1. Priority to solve those reproducible, reproducible bugs are particularly easy to find, repeated debugging test is good, first put the good solution to kill, so the most time-saving.
2. For some bugs do not have a clue or strange phenomenon do not know where to start, looking for experienced colleagues to ask the idea, because in the development of large systems for many years, often repeated the same cause of the bug, the reasons are similar, changed a place, after a while another place, and cannot be cured. For example: My system has a particularly dangerous API, interface parameters are difficult to use, once someone used the wrong situation will be a strange phenomenon, the solution is very simple, find call this API place to write the call way to the right. Why not cure it? Because to maintain compatibility can not change the interface. There are many such rotten APIs in the Windows system. Ask the old staff, maybe they have met several times.
3. Amplification phenomenon, some bug phenomenon is not obvious, then try to increase its destructive, enlarge the phenomenon. This is just a way of thinking, specifically how to enlarge only according to the specific code to decide. For example: The American drama "house Doctor" There is a episode, suspected patients heart and lungs problems, let the patient to run on the treadmill, heavier heart and lungs burden, thereby amplifying the symptoms.
4. Two method positioning, the program logic a little comment out, to see if there will be problems, similar to the two-point search method, gradually narrow the scope of the problem.
5. Simulate the scene, sometimes I ask myself, if I want to implement the phenomenon of bug description, how do I write code?
For example: I encountered a deadlock problem, but the check code found all the locks are paired, did not forget to unlock the place, and the lock is very simple is a normal critical section, a few lines of assignment statements just. How does this code write to make him deadlock? I think if I deliberately create such a phenomenon, only when locked to force the killing of threads.
Since then you can go and see who has a strong kill thread.
6. Make tools to write debugging aids for some bugs. For example, my system does not have a perfect crash report, although there are dump, but the analysis of the callstack is often not allowed. So I wrote a tool to solve the crash problem, which would automatically scan the code and insert log at each function entry and exit to locate the crash point.
7. To cover up the problem, although it is a bit unkind, sometimes it has to be done. Some bugs can't find the real root cause, but they have to be resolved within the prescribed time, so we can treat the symptoms without looking for the cause. Like using try catch to cover up some strange crashes. It is not the last resort to do so, the future may pay a greater price.
How do new programmers find bugs in complex code?
