Jump to content
  • Advertisement
Sign in to follow this  
Terra_Nova

Memory Leaks?

This topic is 2573 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

So I've been having a play around with my game, and I started looking into memory leak detectors, the only thing is practically everything on my game is now getting flagged up.

Now, as far as I can tell, most of these things have nothing wrong.

Here is a snippet from where I'm making a map:

terrain = new CTile*[iHeight]; // The terrain (ground type)
objects = new CTile*[iHeight]; // The objects (trees/buildings etc.)


for(int i = 0; i < iHeight; i++)
{
terrain = new CTile[iWidth];
objects = new CTile[iWidth];
}


I'm dynamically making a multi dimensional array of tiles for an isometric game. The problem is that a after so many allocations it gets flagged up:

{713} normal block at 0x0FC678A8, 5124 bytes long.
Data: < > 00 01 00 00 02 00 00 00 05 00 00 00 01 00 00 CD


Any idea what is going on and how I can troubleshoot this?

Share this post


Link to post
Share on other sites
Advertisement

So I've been having a play around with my game, and I started looking into memory leak detectors, the only thing is practically everything on my game is now getting flagged up.

Now, as far as I can tell, most of these things have nothing wrong.

Here is a snippet from where I'm making a map:

terrain = new CTile*[iHeight]; // The terrain (ground type)
objects = new CTile*[iHeight]; // The objects (trees/buildings etc.)


for(int i = 0; i < iHeight; i++)
{
terrain = new CTile[iWidth];
objects = new CTile[iWidth];
}


I'm dynamically making a multi dimensional array of tiles for an isometric game. The problem is that a after so many allocations it gets flagged up:

{713} normal block at 0x0FC678A8, 5124 bytes long.
Data: < > 00 01 00 00 02 00 00 00 05 00 00 00 01 00 00 CD


Any idea what is going on and how I can troubleshoot this?


Did you tried to actually deallocate these allocation after each iteraction?

Share this post


Link to post
Share on other sites
Well i delete everything when the game closes

for(int i = 0; i < iHeight; i++)
{
delete [] terrain;
delete [] objects;
}

delete [] terrain;
delete [] objects;

terrain = NULL;
objects = NULL;

Share this post


Link to post
Share on other sites
A good leak detector should be able to show you the line of code responsible for the leaked [font="Courier New"]new[/font]. Which are you using?

With your example, other things to consider are the code in CTile's constructor and destructor, whether CTile inherits from other classes, and whether it is ever copied by value.

N.B. You can implement your array of arrays in standard C++ without using new or delete:std::vector<std::vector<CTile>> terrain( iHeight );
for( int i=0; i!=iHeight; ++i )
terrain.resize( iWidth );

Share this post


Link to post
Share on other sites
I was using visual leak detector for a while

and I've been using the whole

#define _CRTDBG_MAP_ALLOC

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include
#include
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif


_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

which is how I found out it was when the tiles were being made.

The thing is its not when the tiles are made, its when the array runs through to the 188th tile

or atleast that is what

_crtBreakAlloc = 712;

brought me to

Share this post


Link to post
Share on other sites
nah, basically my map file goes

height
width
int int int int int int int
int int int int int int int
int int int int int int int...

so it reads in the maps height and width, sets both of the arrays up and then continues to load in all of the map data to fill all the tiles.


When I wrote this before:

terrain = [color="#0000ff"][color="#0000ff"]new CTile*[iHeight]; [color="#008000"][color="#008000"]// The terrain (ground type)
objects = [color="#0000ff"][color="#0000ff"]new CTile*[iHeight]; [color="#008000"][color="#008000"]// The objects (trees/buildings etc.)

right above this is:

MapFile >> iWidth;
MapFile >> iHeight;




Share this post


Link to post
Share on other sites
tbh, I'm not sure whether I've buggered something else up and its having a knock on effect, whether I'm running out of memory, or whether what I'm using to detect leaks is wrong.

This thing has even flagged up a few of the nehe opengl things before - stuff like the tga loader

http://nehe.gamedev.net/tutorial/loading_compressed_and_uncompressed_tga's/22001/

more specifically the line:

imageData=(GLubyte *)malloc(imageSize);

Share this post


Link to post
Share on other sites

tbh, I'm not sure whether I've buggered something else up and its having a knock on effect, whether I'm running out of memory, or whether what I'm using to detect leaks is wrong.

This thing has even flagged up a few of the nehe opengl things before - stuff like the tga loader

http://nehe.gamedev.net/tutorial/loading_compressed_and_uncompressed_tga's/22001/

more specifically the line:

imageData=(GLubyte *)malloc(imageSize);




Everything you allocate with new needs a corresponding delete. Everything you allocate with malloc (or others in the alloc family) needs a corresponding free.

We don't have access to your code so we can't really analyze it to check that all paths will always clean up your memory.

All we can do is guess at causes within the code base we have never seen.

The basic solutions are two-fold. First, you should use container classes, smart pointers, and objects that correctly handle memory even during exeptions or other issues. Second, any class you make should have a clear source of data and a clear sink of data to dispose of it. You need to be extremely careful to follow a source/sink model every time you allocate memory on your own. Commonly the source is either a constructor or initializer function, and the sink is a cleanup function that is also called by the destructor.

Share this post


Link to post
Share on other sites
The important thing to know is that you can get tons of leaks reported and yet actually only have one single leak in your entire program. This is perfectly valid!
The reason is that if one object is not deleted then all of the members it contains are also not deleted, and if those members themselves contain other classes and those contain other objects e.g. strings, you can end up with a huge number of reported leaks all due to the one object not being deallocated.

When a leak is reported, always consider that there may be no actual leaks for that type of object at all in your code, it may be the parent object that is leaking. This applies regardless of what types of pointers / smart pointers you are using.

This is what makes it so hard to retrospectively perform leak detection of your app. You can't easily tell the real leaks from the collateral.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!