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. :)