views:

84

answers:

3

I have a class in a DLL that's used in many other DLLs and EXEs. It has a couple of methods defined in the include file (i.e. the method body is in the .h file) that's included in the other binaries. One of them is giving me fits: int GetVersion() { return nVersion; }.

It is always returning -842150451, but when I run in the debugger and look at the class member variables, nVersion is 100.

Any ideas as to how to debug this problem? I am really stuck.

(Note: This has been working fine for a decade! But now we are moving our code from VC6.0 to VS2005, and it has not been smooth...)

+3  A: 

That value in hex looks like 0xCDCDCDCD which is normally uninitialized memory in a debug build. Are you sure nVersion is initialized?

sean e
Yes, that's the weird thing! If I look at the contents of my class instance, the member variable nVersion is there, and is set to 100, just as I expect.
In the instance that you are checking (in the debugger where the value shows 100), is that a singleton, global or local instance?
sean e
A local instance, I guess you'd say. I create an instance of the class by calling "new". In the debugger, I've got the call, nVers = clas->GetVersion(); and when I hover over 'clas' I can see its member variables, including nVersion, which is 100.
If immediately after the assignment, nVers is 0xCDCDCDCD then I would try rebuild all. I would expect nVers to be 0xCDCDCDCD before the call (unless it is manually initialized to something else).
sean e
If you init nVers to say 0 before the GetVersion() call, what is its value after the call?
sean e
Are all of the binaries being compiled and linked by the same toolset, or are you mixing some binaries built in VC6 with some built in vs2005?
sean e
Oh no! If you mix them, it doesn't work at all. They're all built with VS2005. I set nVers=0 before the GetVersion call, and its value after the call is -842150451.
Are there any conditional members of the class? Is any of the class implemented in source files?Put a breakpoint on the assignment. When you break, switch to mixed disassembly view. Step through the getter and the assignment instruction by instruction. Watch the registers to see where that value is coming from.
sean e
+1  A: 

I had a similar problem related to the not defined initialization order with static variables.

David Feurle
A: 

So if I follow you you've got the equivalent of following going on:

clas=new MyClass();
// some other code executes

clas->SetVersion(100);
/// some other code executes...
/// one line before, nVersion is fine.
int n=clas->GetVersion(); ///< this is where it all goes wrong

(I would have posted a comment however it doesn't format the code)

I'm also assuming that you're sure that the pointer for clas isn't somehow getting corrupted yet pointed to readable/executable memory. (That would hose things a lot)

As for tools to help you debug this, try using a memory profiling tool such as Compuware DevPartner memory analyzer. Others to look into include Purify, Insure++ (which I've also used, and is more powerful, but harder to use)

These tools tend to quickly alert you to easy to make, but hard to find memory errors.

Jason D