Jump to content
  • Advertisement
Sign in to follow this  
Ripiz

[VC++] Memory Leaks

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

I found this FAQ about Memory Leaks and tried to use it in my own program
//Main.h
#include <windows.h>
#include <d3d9.h>
#include <d3dx9.h>
#include <dinput.h>
#include <iostream> 
#include <fstream>
#include <time.h>
#include <vector>
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
/* other includes and variable definitions */

According to that FAQ it should display file where leak happened, however it remains undetailed:
{1445} normal block at 0x01ECC338, 4160 bytes long.
 Data: <@               > 40 10 00 00 08 00 00 00 CD CD CD CD CD CD CD CD 
{1444} normal block at 0x01ECB2B8, 4160 bytes long.
 Data: <@               > 40 10 00 00 08 00 00 00 CD CD CD CD CD CD CD CD 
{1443} normal block at 0x01E8B238, 262208 bytes long.
 Data: <@               > 40 00 04 00 08 00 00 00 CD CD CD CD CD CD CD CD 
{1442} normal block at 0x01E871F8, 16384 bytes long.
 Data: < @       r      > 00 40 00 00 08 00 00 00 E0 72 E8 01 00 00 00 00 
{1441} normal block at 0x01E85478, 7488 bytes long.
 Data: <@           `F  > 40 1D 00 00 08 00 00 00 02 00 00 00 60 46 FF 05 

Could anyone help me please? Thank you in advance

Share this post


Link to post
Share on other sites
Advertisement
You need to overload the new operator to inject the filename and line number into the allocation :


#include <crtdbg.h>
#pragma warning(disable:4291)

void* operator new(size_t size, const char * file, const int line)
{
return ::operator new(size, _NORMAL_BLOCK, file, line);
}

void* operator new[](size_t size, const char * file, const int line)
{
return ::operator new[](size, _NORMAL_BLOCK, file, line);
}

#ifdef _DEBUG
# define DBG_NEW new(__FILE__, __LINE__)
#else
# define DBG_NEW new
#endif



You can then use DBG_NEW in place of new However this won't catch any leaks caused in 3rd party code.

Share this post


Link to post
Share on other sites

//I have this in every file
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

//And this in one of files
void* operator new(size_t size, const char * file, const int line){
return ::operator new(size, _NORMAL_BLOCK, file, line);
}
void* operator new[](size_t size, const char * file, const int line){
return ::operator new[](size, _NORMAL_BLOCK, file, line);
}
#define DBG_NEW new(__FILE__, __LINE__)


However it still output it without ability to detect where leak happens:
{1445} normal block at 0x01E7B528, 4160 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{1444} normal block at 0x01E3B4A8, 262208 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{1443} normal block at 0x01E37468, 16384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{1442} normal block at 0x01E356E8, 7488 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{153} normal block at 0x00C54E38, 2864 bytes long.
Data: < > B4 FE DC 00 01 00 00 01 00 00 00 00 00 00 00 00




Possibly I did something wrong, I'm not very good at C++ yet. Thank you in advance.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ripiz
Sounds complicated... But thanks, I will try.


It's fairly straightforward actually, there shouldn't really be that many places where you use new, try a find in files to find all the places and replace those.

Alternatively you could do the following at the top of each of your cpp files (after including any other headers) :


#define new new(__FILE__, __LINE__)



And let the preprocessor do the replacing for you. I wouldn't recommend leaving this code in though, it's a little bit dirty but should help you track the source of your leaks.

Share this post


Link to post
Share on other sites
Somewhere I found _CrtSetBreakAlloc(long);. It seems to be able to show where leak happens, but it opens include file, and I have to Step Out many times, and sometimes it doesn't show me the place.
Is it good way to find leaks?

Share this post


Link to post
Share on other sites
Yes this is another strategy you can use if you call _CrtSetBreakAlloc(1445) (from your example output) then the IDE should break into the debugger when that allocation happens.

You shouldn't have to step out, take a look at the call stack and find the last function that is one of yours, hopefully that should be one of the allocations that is causing the leak.

Rinse and repeat. I personally think that using debug new to inject the file and line information into the allocation is easier, but whatever works best for you really :) good luck.

Share this post


Link to post
Share on other sites
I don't know how to check last function call, but as far as I understand, Stepping Out will continue code execution, and eventually will lead me back to where it was called, to continue execution of lines after that call.

Also I encountered problem:

Model::Model(char *File, Vector vp, Vector vr, Vector vs){
m_filename="data/";
m_filename+=File;
vecRot=vr;
vecPos=vp;
vecScale=vs;
loaded=false;
alphaLevel=NULL;
alpha=NULL;
Mesh=NULL;
idle=NULL;
/*one of problems happened with File,
I tried free(File), delete File,
delete [] File but I keep getting
program crashed. Any tips?*/

}

Share this post


Link to post
Share on other sites
Debug Menu->Windows->Call Stack.

This should give you a list of the functions that were called in order to get to the current point of execution. In that list should probably be lots of functions that aren't yours, and then further down you should start seeing your functions. Double click on the first function in the list that is yours, hopefully this should show you the allocation which is causing the leak.


/*one of problems happened with File,
I tried free(File), delete File,
delete [] File but I keep getting
program crashed. Any tips?*/




Use std::string...

Out of curiosity...what is the type of m_filename?

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!