Lame opening remarks

I used to do maintenance work of large-scale software for two years. The project lasted for more than 10 years, and there were more than 30 million lines of code. Thousands of people participated in the development of the project. Even the highest priority Showstopper has hundreds. Share my debug experience.

1. Prioritize what’s reproducible

Repeatable bugs are particularly easy to find, repeated debugging and testing is good, the first to solve the elimination, this is the most time saving.

2. Ask a veteran employee

For some bugs, I have no clue or strange phenomena and do not know where to start. I should ask experienced colleagues for ideas, because in the large-scale system that has been developed for many years, bugs of the same reason often appear repeatedly. The reasons are similar.

For example, there is a very dangerous API in my system, the interface parameters are difficult to use, once someone uses the wrong situation, there will be a strange phenomenon, the solution is very simple, find the place to call this API to write the right way. Why not cure it? You can’t change the interface for compatibility. Windows is full of these crappy apis. Ask your older employees. They’ve probably been there many times.

Every day to write a bug

3. Amplification

Some bug phenomena are not obvious, so try to increase its destructive, magnify the phenomenon. This is just an idea, but it depends on the code. For example, in an episode of House, the patient is asked to run on a treadmill to magnify the symptoms by increasing the burden on the heart and lungs.

4. Dichotomous position

Note out the program logic a little bit, see if there will be a problem, similar to binary search method, gradually narrow the scope of the problem.

5. Simulate the scene

Sometimes I ask myself, how do I write code if I want to implement the phenomenon that the bug describes? For example: I have a deadlock problem, but a check of the code shows that all locks are paired, there is no forgetting where to unlock, and the lock is simply a normal critical section that protects a few lines of assignment. How do you write code like that to make it deadlock? I think if I were to intentionally create this phenomenon, the only way to force a thread to be killed is when it’s locked. Since this can go to see who killed threads have not.

6. Make tools

Write debugging AIDS for certain bugs. For example, my system does not have a complete crash report, although there is dump, but the analysis of the Callstack is often inaccurate. So I wrote a tool for fixing crashes that automatically scanned the code and inserted logs at every function entry and exit to locate crashes.

7. Cover up problems

It’s a little rude, but sometimes it has to be done. Some bugs can’t find the true root cause, but need to be resolved within a given time so that we can treat the symptoms without looking for the cause. Try catch to cover up some weird crash. Don’t do this unless you have to, you may pay more in the future.

Never bug

Postscript: For most of the people who change careers, it is really important to find opportunities to complete their basic knowledge and make up the basic knowledge while working.

via：https://www.zhihu.com/question/23019630/answer/23369396

Share my Python learning resources

1 line of code to achieve wechat message sending

How to use RM gracefully to prevent accidental deletions?

Python crawler Entry (Level 3)

Teach you to read web pages in Python

Python crawls “Planet of Knowledge”

Are you still using format to format strings?

Python to spin the Excel