HACKER Q&A
📣 timonpimba

How to fix issue and find the origin of bug in codebase?


I wondered how you people approach a bug problem in the issue section. I have never done these things. Since last week, I've been trying to understand the bug's real issue/origin. I couldn't solve it. Initially, I used git bisect and looked into commits & code. I still couldn't figure it out.

If I could understand how you approach these bugs and how they are fixed, what method do you use, and how do you look at the code to fix them? Then, honestly, it would be invaluable to me.

Also, if you could please share any resources or articles, I would be very interested in looking at them; I could take some lessons from them.

Thanks.

  👤 chistev Accepted Answer ✓
Let's say the bug occurs when you click a button. So you go to the part of the codebase that has logic involving that button, and you analyze the associated functions, if any.
👤 dcminter
One iterative approach; step zero, though, is to be sure you understand what the bug is:

• What happens?

• What did you expect to happen?

If they're the same then NOT A BUG, and WONTFIX :D Assuming it's a bug, the next important thing is to be able to reproduce it. Ideally with a test case. A test case allows you to:

• Rapidly test whether your fix (when you have one) has worked

• Ensure that the bug doesn't reoccur (avoid "regressions")

Sometimes it can be very hard to reproduce a bug, but of course if you can't reproduce it you will never be sure your fixes have worked.

The bug spotting process consists of iterations of:

• Gather data

• Form hypothesis

• Test hypothesis

It's basically the scientific method. Data can be all sorts of things; events occurring in logs, facts about the user's interaction, versions of databases etc. If you have no hypothesis about what's going on, gather more data until you do.

Oh and write your data, hypothesis, and test results down somewhere so you don't get into loops of trying the same thing or think you've tested things that you haven't or know things that you don't.

A hypothesis can be as simple as "maybe it's the version of the database" and the test being "change the version of the database and see if the bug disappears" ... or it could be something more complicated and convoluted ("When this thread does this thing and that one races it to do this other thing with this particular piece of input data then....")

If you were able to reproduce the problem, your hypothesis was correct and the test indicated that you had resolved it, then you're good to go. Then it comes back next week and you discover it was slightly more complicated than that ;)

It's a skill and it improves with practice. Good luck.

---

Edit: Originally I wrote "two approaches" but then realised I really just have this one, but one variant of it is "I recognise something I had at the back of my mind when I was writing the code in the first place" - but that's really just that I already have the data, form the hypothesis off the back of that, and still have to test it to be sure.

Also, before you WONTFIX ... do consider why your expectations and the reporters' expectations conflict. Is your documentation confusing? Are your expectations out of whack with what real users want? Most people aren't just idiots, so a raised bug usually indicates that something is wrong even if it's not the code.