Once there’s a way to reproduce the issue we need to find code which caused it. Sometimes we are totally stuck for day feeling more and more depressed and, in the end, unable to think clearly. Luckily, there’s a systematic approach to find bug even if you have no idea what caused it and even where to set a breakpoint for proper debugging. This approach is known as binary search.

If your code is under version control, firstly you check out a fairly old commit and see if it works. If it does work then you check out a commit that is in the middle between the commit that works and the commit which did not and check again. When there are no commits remaining in between the working and non-working commits, you arrived at the commit that broke it. If you’re using git, you’re lucky since git has built-in tool git bisect that will help with this process. It is quite simple. Let’s say you’re on current master commit and you have a bug.

git bisect # starts the process
git bisect bad # current commit has a bug
git bisect good 3.4.5 # I remember that commit tagged 3.4.5 was OK

After that, git informs you with something like Bisecting: 10 revisions left to test after this, which means there are about 10 commits between good and bad revisions. Also it is checking out a commit which is in the middle of these ten.

Now, it’s your job to confirm if the bug is still present or otherwise. If yes, you issue git bisect bad. If not — git bisect good.

git will choose either left or right part of these 10 commits and repeat the process.

After a few checks, you’ll get, for example, 1029012930192390 is first bad commit message. If you confirmed the presence of the bug correctly, this indicates the exact commit that introduced the issue.

When everything is done you execute git bisect reset to end the process.

Similarly, the binary search approach could be done with HTML markup of a single page when it’s not under version control. If you have a weird bug, delete half of the HTML page code and see if issue is still present. If it is, then divide that HTML and check parts again. If it’s not then take other half for inspection.

The advantage is that you’ll certainly find what caused the bug for certain. However, it is a slow process when you’re not using a tool like git bisect.

The same methodology can be applied to anything. For example, this process widely used in electronics.

• git
• binary search
• bisect

Back to posts