Shulou(Shulou.com)06/01 Report--

Bug should be no stranger to testing or development, although most of the bug we experience has been repaired by others and shared on the Internet, when we find the answer through search engines such as Stackoverflow, Baidu, Google and so on.

But we may also encounter some difficult bug at work, where bug we can not find a solution on the search engine, may be puzzled for several days, these delayed bug often make people worried.

So what difficult bug have you come across as a tough programmer? Next, let's take a look at their story with bug.

Programmer Xiao Luo:

Write JS, my mobile phone is dead, debug with my colleague Lao Zhang's Android phone, and simply get the user's Wechat nickname, but I can't get it alive or dead, and it always shows as null. Should be cross-platform issues, because there is no bug on their own iPhone, desperately reading api documents, but did not mention this aspect. It's killing me.

. Lao Zhang just told me that his nickname is null. . Lao Zhang has been beaten to death. In front of the exaggerated rhetoric, Lao Zhang certainly didn't die in the end, but his leg was broken.

Brother Ma, programmer of e-commerce industry:

Also talk about a bug I encountered. I used to do e-commerce, a larger e-commerce platform, suddenly one day, C2C shopkeeper feedback, see the order is not their own, see the backstage goods list is not their own.

At that time, when I was taking a nap, I woke up immediately when I saw this problem. Usually, five complaints were just a trouble list, and they were all minor problems in experience. This kind of order chaos, the mistake of goods chaos, was really urgent.

As a result, both the supervisor and the director came to look at the problem, and a group of bosses were watching from behind, hurriedly looking for the release in recent days, testing the situation, going back one by one, checking one by one, and finally unable to solve the problem. You know, time goes by. If you can't solve it in half an hour, something big will happen.

Follow-up users to complain, direct telephone contact, remote control of the computer, found that the operation is very slow, so casually asked the user's network is what network.

As a result, he said, "some city broadband". For a moment, I felt a little bit. I continued to ask several other complaining customers that they were all "some city broadband". Then we called the broadband operator and got the reply: "at the end of the year, in order to save traffic, they did some caching."

They cached it. They cached it. Cache... Deposit.

However, the dynamic request of Mao TM is also cached. When modifying goods and orders, success or failure is randomly returned.

1. This has nothing to do with the timestamp. We all added token, and they ignored it.

two。 You guessed right, they also cached the POST and GET dynamic requests, that is, you submitted a request for POST to modify the product, and he casually threw a reply to the user from the ring cache. The user felt that the modification was successful, but in fact, the request did not reach us at all. Yes, it is so insane.

System administrator Lao Wang:

I used to be a system administrator. I used to stand up when I went to the computer room to log on to the server. Once a low back pain, moved a stool to sit in front of the machine, finished, life or death login does not go in, prompt the password is wrong. So I stood up, re-entered the password, and went in.

Later, I thought it was strange, so I took the time to do the test and found that as long as I sat down, the password was wrong and I just stood up.

This Bug has been going on for several years in my career, and I always thought it was some kind of psychic event.

Until one day the company upgraded the equipment and changed my keyboard. It turns out that there are two keys installed upside down on the old keyboard, standing typing is looking at the keyboard, sitting and typing blindly is wrong, it is really speechless ah.

Overseas programmer Steven:

I once heard of a stunning bug and shared it with you. The bug took place at the Massachusetts Institute of Technology, when the system administrator received a call from the dean of the statistics department, who said on the phone, "our mail system cannot be sent 500miles away, or 520miles to be exact."

At this time, the heart of the system administrator is "no waves", huh!

Then he began a long and painstaking test, and finally found that the mail server operating system (SunOS) had been updated, because operating system distributions were often equipped with old software, so the mail software was actually downgraded (Sendmail8-> Sendmail5), and the end result was that Sendmail5 tried to parse Sendmail8's configuration file.

So why does it have to be 500 miles? Let's take a look at the Great God's explanation:

The reason is that in the face of unfamiliar configuration files, Sendmail 5 will ignore all the parts that it does not understand, and automatically set the configuration items that have not been set to 0. So one of them is set to 0, which has always been (timeout to connect to the remote SMTP server) timeout to connect to the remote SMTP server. Later, after experiments, it was found that 0-second timeout would cause Sendmail to break the connection after 3 milliseconds.

So, you ask, why 500miles?

At that time, MIT's campus network did not have that much router, so there was not so much network latency, so the time to connect to a remote host was probably the time required for light. So three milliseconds means:

0.003 "3" 10 8 * 0.001 "0.621" 558.90000000001

558 miles. That is, servers 588 miles away cannot connect, while servers within 588 can communicate normally.

In the face of all kinds of difficult bug, how can programmers change bug quickly and efficiently?

Try the following steps depending on the situation:

1. Try a change of environment.

two。 Try another user.

3. Try a different mode of operation

4. Try changing the data.

5. Try another browser.

6. Try a different version.

Clarify the following questions according to the situation above:

1. Under what circumstances does this BUG appear? Under what circumstances does it not appear? What is the difference between the two situations?

two。 This BUG did not exist before, but now it appears. What has moved in the middle?

3. This BUG production environment appears that the test environment does not appear, what is the difference between the two environments?

4. The same function, this operation does not have BUG, that has BUG, what is the difference between the two operations?

When these problems are clear, try to verify whether BUG will disappear by means of code fallback, configuration adjustment, environment replacement, and so on, and then find out why.

Here are some common troubleshooting BUG types and diagnostic methods for each BUG:

1. The output result is not as expected, and this kind of BUG is usually caused by code logic errors. If it can be reproduced in the development environment, the best solution is to step through debugging, set the expected result of each step of the code, and then track and determine whether the actual result is consistent with the expected result.

two。 In this case, it is necessary to extract the log and find out the error stack information. at this time, the most important thing is to understand and complete the stack information, and often the stack information is output one by one.

3. System Crash, this problem is often caused by high load, high concurrency, or misconfiguration. The most common is memory overflow. At this time, we should first rule out the causes of configuration errors, mainly by looking at the Crash Log to analyze the reasons, and then check the hardware, memory, network and other settings to see if there are any configuration errors. Can no longer be found in the test environment to use development mode for stress testing and debugging.

4. The response of the system is slow. This problem is generally caused by resource competition or insufficient system resources. Check the server content, CPU and network first. If the server is under too much pressure, check whether the application system load is abnormal. If these data are normal, you need to troubleshoot the performance bottleneck in the code. Pay special attention to situations that rely on third-party interfaces, such as sending emails, sending text messages, writing files, and so on.

Summary:

Bug is so strange that not every bug has to go through all the processes. Every step has its difficulties.

Some bug are difficult to locate event points, such as bug in multithreaded and asynchronous logic.

Some of the reasons for the difficulty of bug are difficult to analyze, and most of them are that you can't understand the code.

The difficulty of some bug is that you don't dare to change it, and that's because your modification plan has not been fully analyzed.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.