8 replies to this topic

[Nickie]

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.
http://pastebin.com/hzHb4vSp
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, 10 September 2012 - 05:44 AM.

[Hodgman]

shared_ptr isn't a magic bullet, you've still got to use it with care.
e.g. in this psuedocode, a and b 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.

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;

Is it possible that you have any of these "circular references"?

Edited by Hodgman, 10 September 2012 - 05:47 AM.

[Nickie]

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.

[Hodgman]

In sections where you do need two objects to point to each other, one should be a strong reference (shared_ptr) and one should be a weak reference (weak_ptr, or a raw pointer).

[Nickie]

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 )


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?:

I've seen this code:
#define new new (_FILE_, _LINE_, _LINE);

Any suggestions?

Edited by Nickie, 10 September 2012 - 09:16 AM.

[Bush]

Maybe you should use Valgrind or Deleaker for detecting memory leak?

[fastcall22]

Strange. Maybe here comes this? What is beeing used for?:

I've seen this code:
#define new new (_FILE_, _LINE_, _LINE);

Any suggestions?

This macro tags all of your "new" with additional information -- the file and the line wherein the allocation was made. (Though, it should be new (_NORMAL_BLOCK, __FILE__, __LINE__).) If you haven't already, take a look at the documentation on MSDN on the subject. It is also important to note that a #define 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 new macro and another source file that does not, then allocations with new in the first file will get logged with the additional information and the other source will not.

Edited by fastcall22, 10 September 2012 - 01:56 PM.

[Nickie]

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).

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

_CrtDumpMemoryLeaks();
return 0;
}

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.

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

Edited by Nickie, 11 September 2012 - 04:38 AM.

[fastcall22]

<br />How to avoid these messages, so I can find the real leak? I'm sure these strings are released...

It is, just not at before _CrtDumpMemoryLeaks is called. almost_undetectable_memory_leak is destroyed after main 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).