Archive

Recently, I discovered that sometime in the past, we had developed a bug where only our first conversion would succeed. A stack trace pointed to a memory corruption bug in our converter list. The converter list contains all of the converter objects, which are responsible for everything related to a loaded converter. As a result, they are accessed all over the program, and when I verified that all of them were created properly I was concerned that it was going to be a really nasty issue to resolve. However, as it was a fairly reliable crash that was easy to reproduce I decided to give git bisect a try.

For those who aren’t familiar with git bisect, it is designed for exactly this situation. You provide it with a known good commit and a known bad commit, and I performs a binary search on the commit history, giving you commits to test. After a few re-compiles and some quick test, git bisect helped me determine which commit was responsible for introducing the bug. This commit was “Now converts with a copy of a converter.” It was a one line change, replacing a pointer copy with the creation of a new object using a copy constructor. Class converter has no functional copy constructor, only the default compiler-generated one. Now the source of memory corruption was obvious, we were duplicating pointers, and trying to access them after they had been deleted.

This is exactly the sort of situation where a version control system shines. Because I could look back in time to see what had been done in the past, and because the commit was a small one making a single change, I was able to determine the cause of the problem much more quickly than I would have been able to had I needed to sift through all the code that interacts with converter objects. Lesson learned, commit early, commit often, and use your development tools where they shine, and they will make your job as a developer a lot easier.