Jump to content
  • Advertisement
Sign in to follow this  
Litheon

Memory Corruption: Accessor returns invalid value!

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

If you intended to correct an error in the post then please contact us.

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).
screenshotproblem.png
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.
screenshotproblem2.png

- 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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


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

rrrpa.png

And the T_CallbackObserver is a template class.

Share this post


Link to post
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 this post


Link to post
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 smile.png
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!