• Create Account

### #ActualThe King2

Posted 03 April 2013 - 10:14 AM

For once, it might be even easier if you used PIX (shipped with DirectX sdk) to debug your application. Create a new experiment, set your app as target. Pick second option (something with  "F12"), then press Start Experiment. Now press F12 any time, wait for the "dump" to being made, the app will freeze so long. Exit the app, then you should have a screen with one resource window in the middle. Look at which objects have their attribute "Destruction time" set to "never". Those will be your memory leaks. There will be a lot more of 3 since you most likely are not running DX in debug mode, and the memleaks-output of visual studio is imprecise in DX release mode.

As for the objects shown as never been released in PIX: Of course this will be the device, the backbuffer etc.. but you should also see which resources are never being actually freed.

Also, using those macros would really decrease your code size:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;}
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;}

Some comments on these too: for the SAFE_DELETE_ - macro, the check for x not being null is unnecessary. delete NULL is a valid operation, so if anything this adds more code size (than needed that is, as one can simply write delete/delete[] - but most people don't seem to know that). Plus, setting x to NULL afterwards is unnecessary for most circumstances, seing how in this example everything gets disposed in the destructor anyway, so there is no chance of them being used outside again afterwards. If anything, like in the case that one double-releases/deletes something in the destructor by accident, he might even rather be notified one time to fix the unecessary line. But well, if you REALLY want to be safe and spare that one additional line of typed code, I'd suggest to change those macros to:

//those macros are wide spread but not necessary. use them if you want to save yourself one line of code every now and then, //at the price of a lot of unecessary NULL sets
#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;} //makes the most sense
#define SAFE_DELETE_ARRAY(x) {delete[] (x);(x) = NULL;} //unnecessary, just call delete[]
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;} //unnecessary, just call delete


Those comments should be put there, too, really. Ok, its not that bad, but doesn't it always say we shouldn't be over-exessively using compiler macros anyway? That would make this a perfect case to not use these here, too. But of course you probably didn't know better, I used to use them until I found out some weeks ago that most of the null-checks weren't necessary, too.

### #3The King2

Posted 03 April 2013 - 10:11 AM

For once, it might be even easier if you used PIX (shipped with DirectX sdk) to debug your application. Create a new experiment, set your app as target. Pick second option (something with  "F12"), then press Start Experiment. Now press F12 any time, wait for the "dump" to being made, the app will freeze so long. Exit the app, then you should have a screen with one resource window in the middle. Look at which objects have their attribute "Destruction time" set to "never". Those will be your memory leaks. There will be a lot more of 3 since you most likely are not running DX in debug mode, and the memleaks-output of visual studio is imprecise in DX release mode.

As for the objects shown as never been released in PIX: Of course this will be the device, the backbuffer etc.. but you should also see which resources are never being actually freed.

Also, using those macros would really decrease your code size:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;}
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;}

Some comments on these too: for the SAFE_DELETE_ - macro, the check for x not being null is unnecessary. delete NULL is a valid operation, so if anything this adds more code size (than needed that is, as one can simply write delete/delete[] - but most people don't seem to know that). Plus, setting x to NULL afterwards is unnecessary for most circumstances, seing how in this example everything gets disposed in the destructor anyway, so there is no chance of them being used outside again afterwards. If anything, like in the case that one double-releases/deletes something in the destructor by accident, he might even rather be notified one time to fix the unecessary line. But well, if you REALLY want to be safe and spare that one additional line of typed code, I'd suggest to change those macros to:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) {delete[] (x);(x) = NULL;} //unnecessary, just call delete[]
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;} //unnecessary, just call delete


Those comments should be put there, too, really.

### #2The King2

Posted 03 April 2013 - 10:11 AM

For once, it might be even easier if you used PIX (shipped with DirectX sdk) to debug your application. Create a new experiment, set your app as target. Pick second option (something with  "F12"), then press Start Experiment. Now press F12 any time, wait for the "dump" to being made, the app will freeze so long. Exit the app, then you should have a screen with one resource window in the middle. Look at which objects have their attribute "Destruction time" set to "never". Those will be your memory leaks. There will be a lot more of 3 since you most likely are not running DX in debug mode, and the memleaks-output of visual studio is imprecise in DX release mode.

As for the objects shown as never been released in PIX: Of course this will be the device, the backbuffer etc.. but you should also see which resources are never being actually freed.

Also, using those macros would really decrease your code size:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;}
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;}

Some comments on these too: for the SAFE_DELETE_ - macro, the check for x not being null is unnecessary. delete NULL is a valid operation, so if anything this adds more code size (than needed that is, as one can simply write delete/delete[]). Plus, setting x to NULL afterwards is unnecessary for most circumstances, seing how in this example everything gets disposed in the destructor anyway, so there is no chance of them being used outside again afterwards. If anything, like in the case that one double-releases/deletes something in the destructor by accident, he might even rather be notified one time to fix the unecessary line. But well, if you REALLY want to be safe and spare that one additional line of typed code, I'd suggest to change those macros to:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) {delete[] (x);(x) = NULL;} //unnecessary, just call delete[]
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;} //unnecessary, just call delete


Those comments should be put there, too, really.

### #1The King2

Posted 03 April 2013 - 10:10 AM

For once, it might be even easier if you used PIX (shipped with DirectX sdk) to debug your application. Create a new experiment, set your app as target. Pick second option (something with  "F12"), then press Start Experiment. Now press F12 any time, wait for the "dump" to being made, the app will freeze so long. Exit the app, then you should have a screen with one resource window in the middle. Look at which objects have their attribute "Destruction time" set to "never". Those will be your memory leaks. There will be a lot more of 3 since you most likely are not running DX in debug mode, and the memleaks-output of visual studio is imprecise in DX release mode.

As for the objects shown as never been released in PIX: Of course this will be the device, the backbuffer etc.. but you should also see which resources are never being actually freed.

Also, using those macros would really decrease your code size:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;}
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;}

Some comments on these too: for the SAFE_DELETE_ - macro, the check for x not being null is unnecessary. delete NULL is a valid operation, so if anything this adds more code size. Plus, setting x to NULL afterwards is unnecessary for most circumstances, seing how in this example everything gets disposed in the destructor anyway, so there is no chance of them being used outside again afterwards. If anything, like in the case that one double-releases/deletes something in the destructor by accident, he might even rather be notified one time to fix the unecessary line. But well, if you REALLY want to be safe and spare that one additional line of typed code, I'd suggest to change those macros to:

#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) {delete[] (x);(x) = NULL;} //unnecessary, just call delete[]
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;} //unnecessary, just call delete


Those comments should be put there, too, really.

PARTNERS