Odd memory problems with classes

Started by
44 comments, last by DevFred 12 years, 6 months ago
Last week I finally got around to implementing boost's shared pointers to store my actor objects in a vector. It was working perfectly until I tried adding more functionality to the base actor class. Basically, when in release mode, the objects don't draw if I add too many variables to the class. I bet that both the drawing and the memory limit are effects of a bigger problem.

I chose to turn "GLfloat close" into a magic number in order to temporarily bypass the problem, but now that I have more time I'd like to figure out the real problem. I could have done the same with a different variable, but "close" was the easiest to get rid of. Also, the "memory limit" does not apply to variables of my own classes, like "Quaternion orientation".

My guess is that the real problem has something to do with shared pointers...

class Actor
{

public:
//State
Point position;
Quaternion orientation;

//Speed
Vector moveSpeed;
Vector turnSpeed;

protected:
//Model
GLfloat scale;
Model model;
GLuint UVTexture;

//Speeds
GLfloat moveAccel;
GLfloat turnAccel;
GLfloat moveCap;
GLfloat turnCap;

//Fade
static const long fadeBegin = 70;
static const long fadeEnd = 90;
static const int desiredOpacity = 5;
GLfloat opacity;
//GLfloat close;
//uncommenting this or adding another variable would cause the actors to stop displaying
//If I remember correctly, even though the objects don't display, their members are at least non-null
}
Advertisement
This is likely a poblem of writing to the wrong memory address in another part of your program. Check out other areas of your program where you use pointers to write stuff to.
Wisdom is knowing when to shut up, so try it.
--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.
Agreed - it sounds like you're smashing memory someplace. The primary suspects are anywhere you use raw pointers; shared_ptr is not likely to be the culprit.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Oh, thanks! Hmm...

". . . areas of your program where you use pointers to write stuff to."
Where I am writing to a pointer? The wording of that sentence is a little confusing.

How would I accidentally "smash" memory? Could you give me an example of what to look for? My experience with memory management is minimal. In the meantime, I will look for raw pointers. Do they have to be connected with the actor class in some way, or can they be anywhere?

Thanks!
Scott Wilkewitz
How would I accidentally "smash" memory? Could you give me an example of what to look for?
Usually the culprits are bad loops (looping too many times), or invalid casts (casting a pointer to the wrong type).class Base { int a; };
class Derived : public Base { int b; }
...
Derived* derived = new Derived();
Base base = *derived;//slicing
Derived* pObject = (Derived*)&base;//invalid cast, 'base' is not a 'Derived'
pObject->b = 42;//out of bounds memory write -- pObject points to a 'Base', not a 'Derived'


Object array[42];
for( int i=0; i<52; ++i )
array.foo = bar;//out of bounds memory write on the last 10 iterations
Oh good old buffer overflow. I can't believe you guys thought of that. I hate smart people.
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github
While sudden crashes when making such minor changes usually are a result of trashed memories, as already described above, it might help to ensure you do not have a dependency problem. If one compilation unit was compiled with the old version of your header and another with the new version, bad and weird things are bound to happen. Usually it's an IDE's/makefile's job to recompile all relevant compilation units and in general they do that pretty well, but sometimes things break down (or the user made an error and a proper dependency graph cannot be constructed with the too limited information given).

In a small project, I would suggest to first make a change (like adding a newline where it does not matter), save the header and then trigger a build. All source files which include (explicitly or implicitly) the header must be recompiled, if that does not happen automatically, something with the dependencies is wrong and must be fixed first.

Admittedly, it is rather unlikely that the above issue is the cause of your problem, but I would take a minute to verify it because searching for the cause of trashed memory is generally an extremely time consuming and frequently very frustrating task.
I found that taking a raw pointer of an actor out of my camera class (which is an actor) got rid of the problem. The pointer in question wasn't even being used yet. I also changed all of my methods to use references instead of raw pointers, but that didn't have any effect as far as I am aware.

[s]So did I find the final solution, or did I just find another bypass?[/s]
Edit: I just realized that it was a bypass. Taking the pointer out just got it under the "memory limit."
I'll keep looking for raw pointer use...

Thanks for all the help!
Scott Wilkewitz
Ok, I got rid of all the pointers and the problem still exists.
Bitmaster, could I just rebuild my project, or would I have to add a change to all of my headers?

Thanks!
Try posting your code for review.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

This topic is closed to new replies.

Advertisement