When bits bite

For a few months I have on and off got random crashes in a tool I’m working on. One of those odd bugs where sometimes it works just fine and then suddenly it crashes. You run it again with same data and it works fine. What I had noticed was that it always worked on a fresh run but running the same code repeatedly had a good chance of crashing.

Someone familiar with programming might quickly conclude it’s an uninitialized variable bug. At first I thought so too but I could never find anything that supported that theory. I made sure everything was zeroed out, memory freed, etc, before it would be run but nothing made any difference. For this tool to do what I need it to do, this had to be resolved.

The crash was happening in some free third party code that was written many years ago and it’s quite complex. Today I really started to dig deeper since the crash was happening at the same place in the code every time and was easily reproduced. That’s a good thing for debugging code. So after digging into what was going on in the code I finally realized what the problem was. To give you a hint. Everything was working fine when compiled as a 32 bit app. Ha!

Because of the huge amount of data fed to this tool it needs to be built as a 64 bit app. You can see where this is going. As it turns out, the code is using some pointer bit modification trickery via some macros and this was working just fine with 32 bit pointers. When going to 64 bits it was just pure luck that it worked at all. Only modifying and restoring 32 bits of a 64 bit pointer will not end well. After fixing this it now works like a charm. Interesting bugs can turn up sometimes when old code meets modern realities.