3 ms·

My secret weapon for bug diagnosis is that when a regression is reported on a system without an automatic bisect tool, while everyone else is trying to reason a

My secret weapon for bug diagnosis is that when a regression is reported on a system without an automatic bisect tool, while everyone else is trying to reason about the problem with guesswork and code inspection, I sit down and spend 2 hours just bisecting manually (full sync, rebuild and install of old versions of the software). This provides a guaranteed culprit CL, often one that no one guessed, and also a potential bug assignee who's an expert on the problem in question (the author of that patch). It's "one weird trick" to get bugs stuck in limbo for weeks suddenly making fast progress towards a fix, and all it takes is a willingness to do something so tedious and mindless that no other engineer volunteers to do it.

aidos 6y ago
That approach works well for regressions. I’ve used it myself to track down a bug in chrome and, as you say, having no idea how to fix it, I could direct it to the author via the bug tracker. In my case it was fixed within a couple of days. And obviously bisecting chrome is a slow process, but it only took a couple of hours. I find that most bugs don’t fall into that class, and for the most part, just sitting and picturing the paths back from the bug is enough to work out what’s going on. If you’re less familiar with the code you’ll want it in front of you to trace your way back. In general you can narrow the search space pretty quickly.
munchbunny 6y ago
Definitely agree with that. My own personal experience with difficult bugs is that there is no substitute for taking the time to understand the problem domain, the systems involved, and the code itself. Getting to that point takes significant investment though, and I tend to trust engineers who are willing to do that much more than engineers who don't.
TameAntelope 6y ago
Heh, my answer is that I just refuse to build or work on systems where bugs aren't always super obvious. If the system gets too complex, I bisect the system. I think I've infuriated many colleagues with this attitude, and I'm sure there's at least half of the people here who would similarly be angry working with someone like that. Honestly, I'm not very good at writing software, I just tend to be similar to the author -- I grind more than I out-think most of my problems, and it results in a deliverable that solves it, usually, which ends up being enough to move on with.
ip26 6y ago
However, every time I reason about the problem & debug it, I gain a little knowledge and do it a little faster next time. Bisecting never really gets faster, aside from maybe writing a script.
deleted 6y ago
[deleted]
dehrmann 6y ago
> without an automatic bisect tool At that scale, reading through the commit messages is often enough to narrow it down to a few suspects.

aidos 6y ago

That approach works well for regressions. I’ve used it myself to track down a bug in chrome and, as you say, having no idea how to fix it, I could direct it to the author via the bug tracker. In my case it was fixed within a couple of days. And obviously bisecting chrome is a slow process, but it only took a couple of hours. I find that most bugs don’t fall into that class, and for the most part, just sitting and picturing the paths back from the bug is enough to work out what’s going on. If you’re less familiar with the code you’ll want it in front of you to trace your way back. In general you can narrow the search space pretty quickly.

munchbunny 6y ago

Definitely agree with that. My own personal experience with difficult bugs is that there is no substitute for taking the time to understand the problem domain, the systems involved, and the code itself. Getting to that point takes significant investment though, and I tend to trust engineers who are willing to do that much more than engineers who don't.

TameAntelope 6y ago

Heh, my answer is that I just refuse to build or work on systems where bugs aren't always super obvious. If the system gets too complex, I bisect the system. I think I've infuriated many colleagues with this attitude, and I'm sure there's at least half of the people here who would similarly be angry working with someone like that. Honestly, I'm not very good at writing software, I just tend to be similar to the author -- I grind more than I out-think most of my problems, and it results in a deliverable that solves it, usually, which ends up being enough to move on with.

ip26 6y ago

However, every time I reason about the problem & debug it, I gain a little knowledge and do it a little faster next time. Bisecting never really gets faster, aside from maybe writing a script.

deleted 6y ago

[deleted]

dehrmann 6y ago

> without an automatic bisect tool At that scale, reading through the commit messages is often enough to narrow it down to a few suspects.