hi. i''m using C++ and opengl. my hard drive is thrashing. i''m pretty sure i have all news and deletes accounted for. (i used some windows functions to check.) how else can memory leaks be caused, without new and delete, and the C equivalents? if possible, i''d like to see some example code as to how a leak can be caused without the new and delete operators. or is this even possible? or perhaps it''s an opengl call? if so, what opengl calls can cause memory leaks? thanks for your time. me and my hard drive will appreciate it. a2k

Heres a C/C++ leak using calloc() and free();

int *p = NULL;p = (int *) calloc(sizeof(int));p = (int *) calloc(sizeof(int));free(p); 

Where is the first allocation? You don''t know.

How do you free it without knowing where it is. You don''t, unless there is a function available to free the entire heap.

Mike Roberts
aka milo
mlbobs@telocity.com

no, no alloc, malloc, free, whatever....

a2k

what i'm doing is sorta like this:

//world class (no pun intended)
class WORLD
{
public:
WORLD(){}
~WORLD(){}
PLAYER *player[MAX];
void CreatePlayer(int index)
{
player[index] = new PLAYER;
}
void DeletePlayer(int index)
{
delete player[index];
}
};

//init code

#define MAX 8

WORLD *world;

world = new WORLD();

for(int i = 0; i < numplayers; i++)
{
world->CreatePlayer(i);
}

//in clean up code

for(int i = 0; i < numplayers; i++)
{
world->DeletePlayer(i);
}

delete world;


is this all right? do i need to initialize every member of ALL the objects, and would it cause leaks if i didn't? or is it an OpenGL-related thing? the memory/resources/hard drive space keep going down the longer i run my program. can this possibly be pointer/reference problems in passing functions?




Edited by - a2k on August 1, 2000 12:03:52 AM

are you using multiple rendering contexts. what version of OpenGL and for what video card, or is it the MS software version.

i''m using glut for now. and it''s linked to the SGI OpenGL. i''m using one rendering context. i think. how do i check?

a2k

ok. there are a couple of problems with your code. first of all your "CreatePlayer" and "DeletePlayer" methods should be changed it to something like.

CreatePlayer(int index)
{
if (index < MAX) {
if (player[index] != NULL) delete(player[index]);
player[index] = new(PLAYER);
}
}


DeletePlayer(int index)
{
if (index < MAX) {
if (player[index] != NULL) delete(player[index]);
}
}

and you do not need to initialize all members, however it is good practice to do so. that is what constructors are designed for. and the "new" and "delete" methods do call "malloc" and "free" so, yes you are using dynamic memory allocation.

thanks for the tipper, jenova. but do you think it''ll solve my thrashing prob? i would think it''s something in the main loop, and the code i posted was just all the code that has to do with new/delete.

and also, what i meant with the new/delete, malloc/free, is i was wondering if there were examples of code that demonstrated memory leaks WITHOUT the dynamic allocation of memory, that''s all.

a2k

First off, I''d like to say that I have tracked down many a memory leak in my time and I can not remember ever having one thrash my hard drive. The issue may be the amount of AGP memory that is allocated and the amount of physical RAM that you have. A thrashing hard drive sounds like the OS has gone into virtual RAM and is paging from the drive.

That said, there are some important things to note when using arrays of allocated storage like this. The first is that in the constructor, you need to set all of the pointers to NULL with a quick loop.

for (long x = 0; x < maxObjects; x++) {
objectArray[x] = NULL;
}

The reason for this is that it is perfectly legal to call the delete operator on a NULL pointer. Any ANSI compliant compiler will be fine with this. So when you are deleting objects, you can simply call delete objectArray[x].

Since you are managing players and they may be coming and going from the game at random, you should set the pointer to NULL after deleting it. This serves as a safety net should delete get called again on that element and it serves as a tag later when you check for a free player slot.

Other than these minor issues, your code looks fine. Again, there is nothing there that should cause drive thrashing even if there is a memory leak.

- Carl

In My humble experiece, problems like this are often not the fact that the constrcutor or destructor are bugged, just that the destructor isnt always called.
For one thing, i would write a test function that created 1000 objects then deleted em all, repeat every frame, and let your app run and check that it dosent get slower over time (effectivly artificially accelerate the normal memory leak). If that dosent give you problems then it isnt the destructor.

Then look closely at your code structure, you almost certainly have a set of circumstances which leads to objects being ''lost'' before they get deleted.
heres an example:

i had a game where laser shots were created when fired, and when they ran out of juice, their Update() function would delete em and free us the space.
Also, other code in the game prevented me updating lasers that had been shot offscreen (as there was no need to update something not visible). Im sure you can spot the silly mistake - any shots that went offscreen before they ran out were lost forever and never had Delete() called on em ==== Memory leak.

I think 9 times out of 10 its something like this, not actual init/release code that causes these dang bugs.

Hope this helped

http://www.positech.co.uk

well, it''s just that, i don''t even think it has anything to do with news and deletes, but something in my main game loop. there is no way to have a hard drive thrash WITHOUT dynamic allocation?

if not, it must be something opengl-related or something. i''ve checked all my push and pop matrices, and i can''t think of anything else that could screw it up.

a2k