# Memory Corruption: Accessor returns invalid value!

This topic is 2164 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey everyone,

This is a little bit cry for help, like how the hell do I find this problem. Maybe anyone has some tips.

I'm working in a big project (cross-platform Windows/MacOSX) and I'm having the problem on both operating systems.

I've got a class and it does weird things.

- Sometimes the class contains correct pointers, but when I try to access those pointers from outside they return invalid values
(GetCurrentRenderLayerList() is a dead normal accessor (return currentRenderLayerList_), but it returns 0xcdcdcdcd instead of 0x07c28418 or returns sometimes 0x00000320 and other weird values).

The value in the green circle should be 0, but also got suddenly an invalid value.

- Also sometimes I have the feeling that the memory is shifted by 4 bytes
The "videoMappingResolution_" should have been 800 x 600, but in this case it is shifted, so it is 600 x "invalid value" and the pointer before it got the 800 (0x0000320) value.

- I also have the feeling it sometimes already goes wrong in the constructor or just after. So you create the class and some variables are already badly initialized (in the constructor I try to set all values to NULL and then I see that those values are like 0xcdcdcd or have another value).

The only thing I can think about now is maybe a vtable corruption? How can this be caused? I've checked that I don't call the constructor twice , but I can't find where I'm doing that or so, I don't do anything special in that class. And for arrays I only use std::vector and std::map etc.

So I don't think I overwrite some data with an array.

##### Share on other sites
0xcdcdcdcd is a value assigned to variables allocated with new or malloc that aren't initialised in debug builds.

E.g.
 unsigned int* p = new unsigned int; // *p == 0xcdcdcdcd in debug builds now 

Have you tried doing a full code rebuild?

##### Share on other sites
Also make sure you're not violating the one definition rule anywhere.

One common way that gets violated is when defines aren't consistent across projects and you use the defines to change the class declaration.

##### Share on other sites
Since your project can run on MacOSX, you can use valgrind to help to detect the memory errors.
As far as I remember I managed to compile and use valgrind on MacOSX (maybe only once).

##### Share on other sites
Rebuilding is the first thing I've tried, and I've got it on multiple machines.

I will try valgrins next week (will take ages to run i think on such a big project ), currently I'm trying it with http://www.softwareverify.com/cpp-memory.php on windows. We will see, but I see those things as a last hope ...

Mmmm, but the most "one definition rules" are detected by the compiler no?

Once I could solve the problem by removing a forward declaration (the header file of the class was included + a forward declaration of the class). (Maybe the corruption just moved to somewhere else)

Can forward declaration screw things over?

##### Share on other sites
ahah, now it moved to the constructor! The constructor cant create a valid class

And the T_CallbackObserver is a template class.

##### Share on other sites
Yes Yes, I've found it!

One BAZILLION reputation points for Adam_42!!!!

It was the one definition rule!

The class was derived from the class Observable.

But I've discovered, because somebody did an "additional include directories" in the project properties, that this class existed on 2 places!!!

Thus there were 2 function definitions for each function declaration!

I've discovered it by changing the header guards (which used the same define) to "pragma once" and then the compiler complained about having multiple declarations!

##### Share on other sites

Yes Yes, I've found it!

One BAZILLION reputation points for Adam_42!!!!

Congrats and another zillion points for Adam_42
But, can you show some piece of code to demonstrate your problem?
It's really interesting and I want to know what the exact problem.

##### Share on other sites
Going by the description, the issue was that there's two copies of observable.h in different folders. Let's say they looked like this:

 #ifndef OBSERVABLE_H #define OBSERVABLE_H class Observable { public: int x, y; }; #endif 

 #ifndef OBSERVABLE_H #define OBSERVABLE_H class Observable { private: int z; public: int x, y; }; #endif 

If you end up including different versions in different places (thanks to different include paths passed to the compiler) then they won't agree about the offsets of the x and y variables (and will almost certainly mess up the offsets of variables in derived classes too). This will cause all sorts of weird problems at runtime, but nothing will fail to compile because the public interfaces are identical.

##### Share on other sites

Going by the description, the issue was that there's two copies of observable.h in different folders. Let's say they looked like this:

 #ifndef OBSERVABLE_H #define OBSERVABLE_H class Observable { public: int x, y; }; #endif 

 #ifndef OBSERVABLE_H #define OBSERVABLE_H class Observable { private: int z; public: int x, y; }; #endif 

If you end up including different versions in different places (thanks to different include paths passed to the compiler) then they won't agree about the offsets of the x and y variables (and will almost certainly mess up the offsets of variables in derived classes too). This will cause all sorts of weird problems at runtime, but nothing will fail to compile because the public interfaces are identical.

Exactly!

##### Share on other sites

If you end up including different versions in different places (thanks to different include paths passed to the compiler) then they won't agree about the offsets of the x and y variables (and will almost certainly mess up the offsets of variables in derived classes too). This will cause all sorts of weird problems at runtime, but nothing will fail to compile because the public interfaces are identical.

Thanks for the explanation.
Though I heard ODR before, never knew like that clearly.