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

  • Ice, Ice, Baby

    Much of today could have been sold for scrap, but there was some progress on the refrigerator front. After decanting the contents of the fridge and…

  • One of Those Days

    Overall, it might have been better to stay in bed today, but that wasn't really an option. I am still slogging through a problem at work. I'm going…

  • Comcast At Work

    So we went to watch some TV that we'd recorded on our Comcast X1 DVR and discovered that -- overnight! -- we had gone from less than 50% full to over…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded