0 x00 background

In 2017, construction was completed.

After the Spring Festival, the team put the progress of solving many accumulated problems on the agenda, which made the work of the New Year even more onerous. In fact, many small problems can evolve into more complex ones over time. With the rapid expansion of the product business, how the development team controls the code quality becomes extremely important.

Today I want to reflect on a bug. I don’t care what the bug is today, it doesn’t matter. There were no more than 10 lines of code to fix this bug, but it took a whole week to fix it. I have never spent such a long time looking for a bug, so I feel a little sigh, so I want to record some thoughts and warn myself.

Before we do that, a brief description of where this bug is located:

  • In the project, a third party library was introduced through source code.

  • Changes were made to this third-party library because of architectural requirements;

  • As the architecture changed, more people made changes to it.





Feel it, this is a very frustrating thing… This approach directly leads to the loss of community support, and problems can only be solved internally. By the way, introducing third-party libraries requires two things: careful introduction (necessary code review) and avoiding source modification (through the middle tier if possible).

Using this bug as an introduction, summarize some debug ideas and possible traps and problems. These summaries are not about the above bugs, but more about the daily debug process. Although it is not comprehensive, it is worth exchanging and learning from each other.

0x01 You made the mistake, not the library

Most of the time, that’s the case. Don’t be too sure of yourself, it’s more about not reading the documentation and looking at the code. Of course, people will sympathize with you if you complain about bad apis.

In addition to private libraries, a community-maintained library has to go through tens of thousands of holes and potholes to get to your project. Don’t underestimate those who contribute code to the library. Bugs that are easily triggered are usually fixed the first time. With a little patience, even if the documentation isn’t detailed, it’s easy to spot problems by trying out several demos and different Settings.

Of course, be wary of libraries from individual developers. With the exception of the big labels, all third-party libraries should be reviewed before they are introduced — at the very least, to the bone.

0x02 Follow the lead

This is probably the most common way to debug. Be aware, however, that different debug positions have different effects.

Here’s an example. You have a function that takes in a single piece of data and outputs the result at the console through a complex series of call stacks. Something like this:

input(data) -> a() -> b() -> c() -> ... -> -> z() -> output:"hello world"

When you find output that is not what you expected, you can debug it in two ways: make a breakpoint on input() and work your way through it; Or you can start at z() and follow up to see where the mutation started.

The scenarios are not exactly the same. The former usually happens when you want to understand the flow of the call, which means that you don’t know the whole flow of the call, so you can step through the logic. The latter is often used when the stack and order of calls are known and a function calculation is determined to be faulty, because the intent is obvious: to see if every piece of data in the method stack is as expected.

0x03 Eyes are everywhere and ears are everywhere

At some point, when the actuator is still stuck, an external variable is suddenly changed.

It’s not that surprising, since only the current thread can modify a variable. Don’t always focus on the one piece of code you are currently debugging, but also on other code and even threads. If you care about this variable, find all the ways you can assign to it (write? Cover? Call it what you will). Beware of any changes that may occur in a block of methods that you debug without any changes, immediately after you release them.

There are! Look it up! Do you expect the thread to call the code block every time?

Someone else’s code is not quite what you think it is

“Well. This is return true.”

“Strange… Why not?”

Get over yourself, the code may not be what you think it is. Especially during the troubleshooting phase, don’t skip code if you don’t have to. This is the most deadly and time-consuming thing to do.

0x05 Weeding, high availability

Finding out where the bug is is of course the greatest joy. But remember, if a tool or library is faulty, fix it rather than rely on tweaking business code to do so. At the very least, the tool or library should warn if an external parameter is passed in that it is not valid.

Pay special attention. Tools, or libraries, should be designed to be highly available and can be invoked without error. A common mistake:

    public List<String> find(Data data) {

        int rank = data.rank();

        // ... something else
        // return List
        // ... something else
        // return List

        return null;
    }Copy the code

There is a null branch in the chestnut. This makes the caller extremely vigilant and error prone. The availability is greatly improved if collections.emptyList () is returned. Finally, use notes:

    public List<String> find(@NotNull Data data) {

        int rank = data! =null ? data.rank() : 0;

        // ... something else
        // return List
        // ... something else
        // return List

        return Collections.emptyList();
    }Copy the code

What’s EOF going on about

I haven’t typed on the keyboard for a long time, and I seem to want to write something more. When I look up, it’s late at night. Don’t always stay up late while you are young.

Finished? Come and have a little fun and talk.

Don’t give me any tips. Red envelopes are rotten. > _ <