Bill Roper (billroper) wrote,
Bill Roper

Mystery Bug, Are You Ready For Your Mystery Bug?

So it's bad when the 32-bit C++ calculations work and the 64-bit C++ version of the calculations doesn't. Today was the latest day when I dug back into the problem to find out what the heck had gone wrong, because there's really no reason why a simple difference in the bitness of the compile should be causing the calculations to go awry.

I fairly quickly found a problem with the account filtering function that was causing it to exclude accounts with subaccounts on the C++ side and to exclude the subaccounts on the Java side of the universe. That problem was definitely a suspect, so I cleaned it up. This is what happens when you keep rearranging exactly how the subaccounts are going to work in the revised architecture.

Sadly, this did not fix the problem. On the other hand, it was probably just as well that it didn't, because that code failed in both the 32-bit and 64-bit C++ versions before the fix, so it couldn't explain why one worked and the other didn't.

Back into the debugger. I finally discovered that one of my functions that was looking up a data array in the 64-bit version was returning NULL. What the heck?

See, I had a base class in C++ that provided the definition of an implementation and a derived class that actually implements all of the functions. In the base class, I defined:

virtual MyArray* GetArray( INT_PTR i ) { return NULL; } // probably should have just been an pure virtual function definition, I suppose

In the derived class, I defined:

virtual MyArray* GetArray( int i ); // one of these things is not like the other in 64-bit land

In the 32-bit compile, INT_PTR is substituted by int and everything works correctly.

In the 64-bit compile, INT_PTR is a distinct type from int. Everything compiles happily, but you will never get to the function in the derived class when you call through a base class pointer, because the "overriding" function implementation has a different signature and never overrides the base class implementation.

*thud* *thud* *thud*

I'm sure this was correct at one time or another, but with all of the merges that have been done on this particular code line and the various hands that were trying to clean up 32/64-bit compile problems, this one got missed.

Ah, well. Fixed now. :)
Tags: c++, computers, microsoft, musings, tech, work

  • Long Day

    It was a long day, but the refactoring that I started yesterday is done, at least for a bit. Tomorrow, it's back to debugging. :)

  • The X-Refactor

    I actually don't so much mind refactoring code, as long as I am doing something that will improve the code base. For instance, today I worked with…

  • Sofa, So Good

    They were having one of their periodic sales at La-Z-Boy this weekend. Given the condition of the sleeper sofa in the living room and the couch in…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded