Nine methods of debugging: How to troubleshoot software and hardware errors

Debug the 9-way outline Mind Map

Text Summary

 

Understanding SYSTEM

This is the first stock, because it is the most important.

• Read the manual. It will tell you to apply lubricating oil to the weeding head when using the lawn machine, so that the weeding rope will not be burned.

• Read every detail carefully. Details about how the microprocessor handles interruptions are hidden on page 37th of the Data Manual.

• Master basic knowledge. Data points will generate a lot of noise.

• Understand the workflow. The engine speed may be different from the tire speed, which is caused by the drive shaft.

• Understand tools. Find out which end of the thermometer is used to measure the temperature and how the powerful functions of the glitch-o-matic logical analyzer are used.

• View Details. Even Einstein looked at the details, while kneejerk blindly believed in his memory.

 

Manufacturing failed

Although it looks simple, debugging will become very difficult if the manufacturing fails.

• Manufacturing failed. The purpose is to observe it, find the cause, and check whether it has been fixed.

• Start from scratch. The car repairer needs to know that you have washed the car before the car windows are frozen.

• Cause failure. Use a sprinkler to spray water on the window that leaks.

• But do not simulate failure. Use a sprinkler to spray water on the window that leaks, rather than on a different, similar window.

• Search for conditions that are not under your control (which leads to intermittent failure ). Change everything that can be changed, vibrate, shake, and twist until the reproduction fails.

• Record everything and find the characteristics of intermittent bugs. Our binding system always fails only when the call order is disordered.

• Do not trust statistics too much. The binding seems to be related to the time period, but the real reason is that the local young people occupy the telephone line.

• We need to realize that "that" may happen. Even the taste of ice cream affects the launch of cars.

• Never lose a debugging tool. The automatic hitting plate may be useful one day.

 

Don't think about it, but watch it.

As you can imagine, there may be thousands of problems. The actual cause can be found only when you see it.

• Failed to observe. The Senior Engineer saw the real problem and was able to find the cause. Junior engineers think that they know where the error occurred, and the result is that they have not fixed the problem.

• View Details. Do not stop when the water pump appears to sound. Find out which pump is in the basement.

• Insert a plug-in tool. Use the source code debugger, debugging logs, status messages, traffic signals, and bad eggs.

• Add an external plug-in tool. Analyzer, oscilloscope, table, metal detector, ECG, and soap bubble are used.

• Do not be afraid to study in depth. Although it is a finished software product, but it has a problem, you must open it and fix it.

• Pay attention to the heenburg effect. Do not let the instrument affect the system.

• This is just to determine the search focus. Boldly guess that the memory sequence is wrong, but you should check it before fixing it.

 

Divide and conquer

It is difficult to hide a bug when its hiding location is halved.

• Narrow the search range by means of successive approximation. Guess 1 ~ A number within 100, only 7 times.

• Determine the range. If the number is 125, but you think it is in 1 ~ Within 100, you must expand the scope.

• Determine which side of the bug you are on. If your location has emissions, the emissions are in the upstream. If there is no emission, the emission management is downstream.

• Use an easy-to-view test mode. It starts with clean and clear water so that it is easy to see when emissions enter the river.

• Search from the problematic end. If you verify the correct part, there are too many places to verify. Start from where there is a problem, and then trace the cause.

• Fix known bugs. Bugs are mutually protected and hidden. So fix them immediately once they are found.

• First, eliminate noise interference. Pay attention to the factors that cause system problems. However, do not be too extreme about insignificant issues, or repair all places in pursuit of perfection.

 

Change only one place at a time

We must have a foresight in our lives. If your changes do not play the expected role, change them back. They may have unexpected effects.

• Isolate key factors. If you are checking the effects of sunshine time, do not change the irrigation plan.

• Hold the brass rod with both hands. If you try to repair a nuclear submarine without knowing what's going on, it may trigger an underwater accident of the chernob.

• Change only one test at a time. I know that my VGA collection phase is damaged because nothing else has changed.

• Compare with normal conditions. If all errors have some characteristics that are not normal, you can find the problem.

• Determine where you have changed since the last normal operation. My workmates changed The Changers on the turntable, so this is a good starting point for debugging.

 

Keep audit trail

Do not simply remember the rule "Keep audit trail", but write it down.

• Record all the operation and Operation Sequence and results. When was the last time you drank coffee? When did your headache begin?

• You must know that any details may be important. The collapse of the video compression chip is caused by the lattice shirt.

• Associate events. "It emits noise. Starting from 21:03:53, it lasted 4 seconds, which is much better than simply saying "it emits noise.

• Audit tracking for design is also very useful in testing. The software configuration control tool can tell you which revision introduced bugs.

• Record things! No matter how terrible the moment is, remember it in the memorandum so that you will not forget it.

 

Check plug

Some obvious assumptions are often incorrect. Let me describe it in detail. It is assumed that an error is usually the easiest to fix.

• Question your assumptions. Is the correct code running? Is the gas used up? Whether the plug has been inserted.

• Start from scratch. Is the memory properly initialized? Have you pressed the "Primer bulb" button on the host? Is the switch enabled?

• Test the tool. Is the Correct Compiler running? Is the fuel oil table stuck? Is the scale out of power?

 

Get new ideas

In any case, you need to take a break and have a cup of coffee.

• Ask for comments from others. Even a human model that does not speak can help you recognize things you have not noticed before.

• Obtain professional knowledge. Only the manufacturer of the VGA video capture card can be sure that the phase function is incorrect.

• Listen to others' experiences. Someone else will tell you that the ceiling light line in the car has been squeezed out.

• Help is everywhere. Colleagues, suppliers, networks, and bookstores are waiting to help you.

• Put down the face. The bug has occurred. Take pride in removing bugs, rather than being proud of removing them by yourself.

• Report the symptoms instead of your theory. Do not drag others into your mindset.

• You don't have to be very certain about your question. You can even ask for something like "wearing a plaid shirt.

 

If you do not fix the bug, it still exists.

Now that you have mastered all the technologies, there is no reason to let the bug exist.

• Check whether the problem has been fixed. Do not assume it is a circuit problem, but still let the car carry dirty oil filter mouth.

• Verify that your repair solution solves the problem. Shouting "Wubba !" It is not a trick to enable a computer.

• You know, bugs will never disappear. Use the method that originally caused it to fail to create again. If a product must be delivered, design a "trap" in the product to capture bugs ". So that the product can be caught when the customer fails.

• Fundamentally solve the problem. Before burning another transformer, discard useless 8-track tape blocks.

• Fix the process. Do not just erase the oil from the ground, but correct the design method of the machine.

 

First, the writing is thick, and then the writing is thin. This is a well-understood book with clear themes. But the content of this book is not simple, debugging is a great learning. In my daily work, my debugging methods often appear in books, but there is no rule. I randomly debug them to see the current situation. The author summarized the method as a scientific method and found the problem step by step. This is the author's greatness and found the law in chaos.

Furthermore, the book structure is very good. Each chapter has its own summary, and the structure is very emotional. Readers do not need to clarify their own clues and present more important parts.

This is a very good book. We suggest you have time to read it. The methods are universal and can be applied in different scenarios.

 

Speaking of other things, I recently used to overcome procrastination, activate a blog, and write a blog. Therefore, I am still confused in all aspects, such as the application of Mind Map and blog writing, I hope you can provide more guidance and suggestions. This is also my hope. from one point to the other, it will be counterproductive and create a win-win situation for everyone to improve. I strive to write something every week. First, I want to share something I learned, and then I want to be original. There is not much time to study at ordinary times, and the analysis is still one to two weeks behind. Today, I drew a mind map and used multiple desktops in Ubuntu. I found that switching is really convenient. With xmind, it is good to use.

Nine methods of debugging: How to troubleshoot software and hardware errors