Choosing a provocative debug signature
Back in Windows 95, there was an elusive heap corruption bug in the graphics engine, and after a lot of analysis, the graphics folks were convinced that the corruption was coming from outside their component, and they had a pretty good idea who the corruptor was, but they needed proof. One of the standard techniques of narrowing down the source of a problem like this is to put a signature value in the object and validating the signature on entry to every function that uses that object as well as on exit. If you find that the signature was valid on entry but is corrupted on exit, then your function corrupted it. Conversely, if it was valid on exit but is invalid on a subsequent entry, then somebody else corrupted it. At least that’s the theory. The developer who was responsible for investigating the bug decided to use this “signature value” technique. It is often the case that, for throwaway temporary signatures like this, you will use your own initials as the signature value. This is partly egotism but mostly just lack of creativity. But this particular developer had a better idea. Since he had a pretty good idea which component was corrupting the memory, he used not his own initials, but the initials of the developer responsible for the component he thought was the corruptor! That way, when that developer’s component corrupted the signature, it’d just be corrupting his own initials. Of course, when the developer of the suspect component saw this check-in, he felt kind of insulted. After all, his friend just accused him of corrupting memory.
(Epilogue: It turns out that the graphics folks were right. It was that other component that was corrupting the memory.)
Light
Dark
0 comments