Sign in to follow this  
Nickie

Strange Memory Leaks...

Recommended Posts

So I decided the check the memory usage of my program. I ran it and opened win7's resource manager.
I noticed the memory usage is incresed by 200 kb each second. Is it normal?
I actually have many tiny allocation on runtime(I know it is bad idea, thats why I've got plan B if it eat too much performance later)
Also MSVC is telling me I have maaaanyyyyy memory leaks.
[url="http://pastebin.com/hzHb4vSp"]http://pastebin.com/hzHb4vSp[/url]
I checked all my code. All new's I have ever used in this project are in std::tr1::shared_ptr. Except one but I double checked it, it is beeing freed when it is time.
Maybe my singletons(I have 2 global singletons -> Event Manager and String manager) and freed later? Actually where are they released? Their objects are in shared_ptrs.

Or I haven't used the right macros?
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
this is at the beginning of my main.h(right after pragma once)

_CrtDumpMemoryLeaks(); this is right before return;

I've seen this code:
#define new new (_FILE_, _LINE_, _LINE);
or something like this. I don't have such thing. What is it beeing used for? Is it required?


PS. I'm thinking of possible memory fragmentation. I have something like 4-5 new for 8-16 bytes each frame. I also destruct them the same frame or the next. Is it possible? Edited by Nickie

Share this post


Link to post
Share on other sites
shared_ptr isn't a magic bullet, you've still got to use it with care.
e.g. in this psuedocode, [font=courier new,courier,monospace]a[/font] and [font=courier new,courier,monospace]b[/font] are leaked, because even though they're now "inaccessible" they both point to each other in a circle, meaning they never reach a reference count of 0.[code]struct Widget { shared_ptr<Widget> next; }
shared_ptr<Widget> a = new Widget;
shared_ptr<Widget> b = new Widget;
a->next = b;
b->next = a;
a = nullptr;
b = nullptr;[/code]Is it possible that you have any of these "circular references"? Edited by Hodgman

Share this post


Link to post
Share on other sites
Actually I though about this. It is possible only in my hierachies. (parent + child ptrs)
And still it is telling me for large amout of leaks. But I've got idea. I'll record their count(or lines) and then put manual destruction of the hierarchies. And then I'll see if there is difference.

Share this post


Link to post
Share on other sites
Ok. I fixed my destruction method of the hierarchies. -500 lines of memory leaks. Still 2000 left. Hmh.. I'll review my whole design for more of these circulars, however it will take time. I'll write here as soon as I'm done. Thanks.(I hope there won't be memory leaks after fixing them [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img])


I managed to take the memory leaks to 400 lines. I was actually right. It is thinking about my globals as memory leaks.
I have made a table like this:
ID, STRING, REF Count
And I'm actually keeping just the id in the strings. This gives really fast comparing.
And I have made for example a new actor event:

static const RE_String new_actor = "NewActor"; // this way the lookup for id is done just once at init

Strange. Maybe here comes this? What is beeing used for?:
[quote]I've seen this code:
#define new new (_FILE_, _LINE_, _LINE);[/quote]
Any suggestions? Edited by Nickie

Share this post


Link to post
Share on other sites
[quote name='Nickie' timestamp='1347279325' post='4978550']Strange. Maybe here comes this? What is beeing used for?:
[quote]I've seen this code:
#define new new (_FILE_, _LINE_, _LINE);
[/quote]
Any suggestions?[/quote]

This macro tags all of your "new" with additional information -- the file and the line wherein the allocation was made. (Though, it should be [tt]new (_NORMAL_BLOCK, __FILE__, __LINE__)[/tt].) If you haven't already, take a look at the [url=http://msdn.microsoft.com/en-us/library/x98tx3cf%28v=vs.100%29.aspx]documentation on MSDN[/url] on the subject. It is also important to note that a [tt]#define[/tt] in one header file isn't neccessarily applied everywhere else to your project. Remember, the contents of a header file are dumped into the source file that includes it and each source file is compiled separately. If you have one source file that includes a set of headers that eventually defines the [tt]new[/tt] macro and another source file that does not, then allocations with [tt]new[/tt] in the first file will get logged with the additional information and the other source will not. Edited by fastcall22

Share this post


Link to post
Share on other sites
So... The guy who posted the links for deleaker. Thank you. I was albe to fix my memory leaks alone. However. using deleaker I found that most of the leaks are comming from DXUT. This means that my program is not behaving correctly on lost/reset/create device/etc. There are my problems comming from. Gonna check the samples DXSDK is comming with. I think I'm destorying the resources in a wrong callback(if I didn't do it anythwere DXUT whoud popup a leak message).


[CODE]
#include <memory>
#include <iostream>
std::string almost_undetectable_memory_leak = "hello world!";
int main()
{

_CrtDumpMemoryLeaks();
return 0;
}
[/CODE]

[CODE]
Detected memory leaks!
Dumping objects ->
{143} normal block at 0x00654E68, 8 bytes long.
Data: < 5 > A0 D1 35 01 00 00 00 00
Object dump complete.
[/CODE]

How to avoid these messages, so I can find the real leak? I'm sure these strings are released... Edited by Nickie

Share this post


Link to post
Share on other sites
[quote name='Nickie' timestamp='1347357047' post='4978842']<br />How to avoid these messages, so I can find the real leak? I'm sure these strings are released...[/quote]

It is, just not at before [tt]_CrtDumpMemoryLeaks[/tt] is called. [tt]almost_undetectable_memory_leak[/tt] is destroyed after [tt]main[/tt] returns. To solve: restrict all objects to the tightest scope allowed -- avoid global objects (and by doing so, you'll avoid the static initialization order fiasco as well).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this