This method was popularized by git, which ships with a built-in bisection tool aptly named ‘git bisect’. With an initial search space of 130,000 commits, you end up only having to test log 2 (130,000) ≅ 17 steps!.You can just repeat this process recursively and cut your search space in half at each step (logarithmic approach). If MID is buggy, the bug was introduced in the former half.If MID is working properly, the bug was introduced in the latter half.By testing a commit ‘MID’ exactly in the middle you can obtain a new boundary and cut the search space in half. Let’s say you have a previous commit showing the correct behaviour ‘GOOD’ and the current bad one, ‘BAD’.The idea of source code bisection is to optimize the number of commits you have to test by checking them, like how you would look up a word in a dictionary. In the case of the Linux kernel, the number of commits between two releases can go as high as hundreds of thousands. You could painstakingly go through every single version stored in your Version Control System but this might take a while. If you have access to the source code of your client or server and are seeing some new buggy behaviour that wasn’t there a couple of versions ago, it means the bug was introduced somewhere in between. The last section is about a new tool I wrote to diff network captures as if they were text files. Some of the finer details are about SMB but the general idea is probably generic enough to be used for any protocol. Exploring all those possibilities takes a lot of time and effort so ideally, you want to reduce and narrow things down before you start a deep dive.Īfter debugging server message block (SMB) issues for a couple of years while working on the Linux kernel client and Samba server, I have found a couple of tricks and techniques that seem to work well for me and hopefully will work well for you.
0 kommentar(er)
