Jump to content
  • Advertisement
Sign in to follow this  
ThrakhathZero

Proper Methods of Tracking down Memory Leaks

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

First time here, I poked around the net and didn't find a satisfactory answer, so I thought I'd see what this community is all about and see if you guys had some good advice. Be Gentle, please, I break easily ;) Okay, so I've written a small Tetris-clone in C++ using DirectX 9. It uses a basic Cube stored in an .x file, painted with different .bmp textures for pretty much every currently visable object. The edges of the field are just these cubes with a 'border' texture and the game block are arrangements of these Cubes textured with a mono-color .bmp. Currently, it plays fine (sans sound, I haven't done anything with DirectSound just yet), blocks falling, colliding, clearing, scoring, etc. The game also escapes 'fine' if I'm not debugging. I put it in debug mode and I find that at least one object in not being properly released. Now, I know I could find it be just checking every object, every time I use new(), etc. But I can't think this is a good practice, certainly wouldn't be viable if this were a large-scale game and not a tiny bare-bones clone. So I thought I'd take this chance to find out how one goes about properly tracking down a Memory Leak, and maybe some of the good coding practices that go into NOT making leaks. So far I have tried: - Including d3dx9d.lib and #define'ing D3D_DEBUG_INFO, but this seems to just say "You have a leak" without telling me where - Setting the Debug output in the DirectX Control Panel to various levels of output (still have no idea what the exact differences are except More v Less), but it doesn't seem to change the output. I still get what looks like a stack trace/dump - Setting 'Break on Memory Leaks' but it only seems to breakpoint after the game is all done (after cleanup code and exit codes and whatnot) - Setting 'Break On AllocID' and setting some of the Alloc ID's from the debug output, but this seems to breakpoint in the library fuctions, not in my code, so I still don't know what object is at fault. Any tips would be appreciated. Also, I was wondering what the differences between using delete[] and using a d3d Objects Release() function. Should I be doing both? In what order? Is d3dObject->Release() enough? If I have all my delete/release calls in one function (Cleanup() for example), where's the best place to put the call to make sure it's always called and only called once?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
You should never use delete on d3d objects. delete is used to free the objects created by new. You should always use object->Release() on d3d objects . d3d objects use a reference count system. there is a function to increment the reference count (I don't remember it's name now), and there is Release to decrement the reference count. When the reference count goes to zero, the object is destroyed. If you want to avoid memory leaks with your objects, you could consider using boost::shared_ptr, it's easy to use and powerfull.

Share this post


Link to post
Share on other sites
How about using a little tool to help you - valgrind seems perfect for your problem. It's free and as long as you compile with debugging info you should be able to locate the source of your memory leak pretty soon.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!