sizeof(myclass) acting strangely.

[Radius]

Hello,

I have encountered a serious problem in my mode and was hoping someone may have a suggestion.

I have a 3rd party library (cringe) and I have used it successfully in many projects. For the last 2 weeks I have been looking for a mysterious crash and I found the cause now.

I have a MDI application and the control is initialized in a form, derived from CFormView for a child window. Everything works great. In fact, anywhere in the whole application I call sizeof(theclass) I get the proper size.

Except my DOC class for the project. Whenever I access a couple of public variables from the DOC I get crashes. Turns out if I get the size of the class, it is 48 bytes less than anywhere else in the application. This causes all my data members to be completely wrong and in the wrong locations.

I have looked at the assembly code and sure enough only in the DOC class is the wrong offsets being added to the member variable references which I expected.

I have tried forcing padding and alignment but no luck. I have the sources for the 3rd party library but nothing in there forces padding or alignment. And as I say I use this library successfully in many places and I always use it the same way.

Does anyone have even a slight hint where I should start looking for this problem?

Thanks.

[Skizmo]

You can't take the size of a class. Period. The fact that it sometimes works is pure luck.

Why do you need the size of a class anyway ?

[GCDEF]

I think the more important question is why you need the size of your doc class.

[laserlight]

You can't take the size of a class. Period. The fact that it sometimes works is pure luck.

No, you can take the size of the class. It is not a matter of luck. What you cannot safely do is rely on the size obtained.

Why do you need the size of a class anyway ?

I think the more important question is why you need the size of your doc class.

My impression is that Radius checked the size of the class in an attempt to find the cause of the crash.

[Radius]

Ok sorry, maybe I didn't describe it well enough, I'm a little fried at the moment.

I mean the size of the class definition not the declaration, so MY_CLASS myclass;

I do sizeof(MY_CLASS);

The reason fir this is because I discovered that getting a pointer to a member variable in the form class consistently returned a value 48 bytes less than the position it was actually stored at. So in the form class I get the memory location of an int following MY_CLASS and it is different than getting the location from the DOC class.

The DOC class always assumes the member variables following MY_CLASS are 48 bytes less than their actual position. The sizeof() check was a last ditch attempt to see if something funny was going on with the actual class itself.

[Lindley]

Is the mystery class being built at the same time, or is it something pre-built that's just now being linked in?

[GCDEF]

The reason fir this is because I discovered that getting a pointer to a member variable in the form class consistently returned a value 48 bytes less than the position it was actually stored at. S

Why are you doing it that way? Sounds like you're trying to get pointers to members using offsets. That's an incredibly bad idea.

[laserlight]

The DOC class always assumes the member variables following MY_CLASS are 48 bytes less than their actual position.

Do you say this as an observation, or as a note on the implementation?

I think that you need to clarify what the implementation does and the steps you took to debug. At the moment the difference is ambiguous.

[Radius]

The library is built in the same project, the build order includes it as the first item like all my other projects.

Why are you doing it that way? Sounds like you're trying to get pointers to members using offsets. That's an incredibly bad idea.

Here's what I do:

Form class: int *x = &iVar; // Let's say it == 0x530 for fun.

DOC class: int *x = &myForm->iVar; // Now it is 0x500.

But this only applies to member variables after the 3rd party class. And ONLY applies to the DOC class. All other classes in the application do not exhibit this behavior.

[Radius]

Do you say this as an observation, or as a note on the implementation?

I think that you need to clarify what the implementation does and the steps you took to debug. At the moment the difference is ambiguous.

Direct observation getting the pointers to the member variables.

[Radius]

Sorry, if this is too unclear I can post some more robust code. I was trying to keep it simple as not too flood with too much useless info but maybe that was not the best approach.

[edit]

Another thing to note, I have looked at the assembly code for this, and I can see in the DOC class only the offsets to the member variables are completely wrong. In ASM, the pointer to the class is loaded, and then a hard coded offset is added in order to load the data at the member variable.

Pseudo code:

Mov eax, <the pointer to the form class>
Add eax, 0BA4h // references iVar
// do some other stuff.

But only in the DOC class is this number wrong, 0x30 bytes less than it should be. It is as though the DOC class is thinking the member variables are at a different offset than they really are. This is what has me so confused.

[GCDEF]

The library is built in the same project, the build order includes it as the first item like all my other projects.



Here's what I do:

Form class: int *x = &iVar; // Let's say it == 0x530 for fun.

DOC class: int *x = &myForm->iVar; // Now it is 0x500.

But this only applies to member variables after the 3rd party class. And ONLY applies to the DOC class. All other classes in the application do not exhibit this behavior.

Are you sure you only have one doc object? Check the doc pointer and the this pointer from inside the doc and make sure you're looking at the same object.

[Radius]

Are you sure you only have one doc object? Check the doc pointer and the this pointer from inside the doc and make sure you're looking at the same object.

Yes, I have not only checked that but every class pointer, member var and even gone so far as checking hWnd values for all relevant member variables and parent classes. I have been at this for quite some time now.

[kirants]

Is the third party library a DLL?
Are you passing C++ objects from your code to the third party code?

Sounds like a case of memory corruption to me.

[Radius]

It is a 3rd party library, but only interfacing using regular function calls and nothing else.

I thought memory corruption too but no memory checkers are alerting on anything, and the fact that the wrong offsets are compiled into the assembly code is really making me wonder if I haven't somehow made this particular DOC class think it's padded or aligned differently.

Anyhow, I am exploring all options here. I hope it is just a simple compiler switch I missed or something. The usual culprit anyhow.

Thanks everyone for the input!