What memory leak detector do you use?

[DrEnzyme]

I was told recently that memory leak detectors such as VLD and the CRT memory leak detector to return "false positives" with SFML (I'm using C++ with my engine). From what Laurent was saying, some of the memory is cleaned up after the program terminates. This presents a bit of a problem for me, as there's no easy way for me to see if my program is leaking memory in other places. Does anyone have any good recommendations for memory leak detectors that are able to get around this problem? Is there any other way to solve this?

[zsbzsb]

Don't use raw pointers and manual memory management, instead use RAII and smart pointers and then you won't have to worry about memory leaks.

Oh and why is this in the C binding section?

[binary1248]

First of all, the question has to be asked what you consider as a "leak". It is true that sometimes things are reported that at first glance seem like false positives, but theoretically they can still be classified as leaks depending on the definition. Also, another thing to consider is that even if you find an alleged leak, can SFML or your code do anything about it? Most of the reported leaks that I have encountered running simple SFML examples come right out of the graphics driver, and when that happens the only thing you can do is ignore them.

The second question that has to be asked is: why do you need a leak detector? I used to use leak detection tools a lot in the past, but these days, I've just gotten accustomed to writing code that has no way to leak at all. Trust me when I say the little bit of effort you put into doing that outweighs the effort you will spend in tracking down and eliminating leaks that happen to pop up. Modern C++ also provides standardized ways of avoiding potential sources of leaks all together. Back when I used to deal with leaks, such things were only provided in libraries or had to be written by oneself making it easier to just deal with the leaks when they happen. Modern C++ code has made leak detectors kind of obsolete, at least if it conforms to common practice. There are already so many posts on this forum that deal with coding style and memory management and even a section in the FAQ, hence I won't spend unneeded time copying and pasting what has already been said.

If you insist that your source of leaks are absolutely unavoidable or for some reason the cost of dealing with their source outweighs the effort needed to find and eliminate them, then you can check out valgrind if you have access to a Linux machine. In my opinion it is easier to find leaks on Linux machines because the tools are provided more and easier access to the data they need to instrument the execution of a binary better than say on Windows. If you are looking for state-of-the-art leak detection, get a working LLVM/clang toolchain and run its numerous sanitizers over your code/executable. I've yet to see a more performant suite of tools that offer the same amount of integration of static and dynamic analysis into the instrumentation (and on top of that, it's completely free).

[DrEnzyme]

Don't use raw pointers and manual memory management, instead use RAII and smart pointers and then you won't have to worry about memory leaks.

This is a good idea. I've never used smart pointers before, so I shall consider using them in my game code, but there are reasons I don't want to be using them all over the place. My engine is already written (it has been built over about a half-decade) so I don't want to spend a lot of time re-factoring it, nor do I want to worry about the overhead of using a non-basic form of object instantiation. Finally, I want to have reasonably tight control over the memory I'm using, in games it is sometimes advantageous to know when an object is getting deleted. For instance, if I am making a simulation game where I need to clean up 100 dead enemies after a bloody battle, I don't want them to be deleted all at once and potentially lagging the game.

Oh and why is this in the C binding section?

I didn't know where to put it. It's specific to C++ so I didn't think it should go in the general section, but it's got nothing to do with "binding." Maybe someone can move this to where it's supposed to go?

First of all, the question has to be asked what you consider as a "leak". It is true that sometimes things are reported that at first glance seem like false positives, but theoretically they can still be classified as leaks depending on the definition. Also, another thing to consider is that even if you find an alleged leak, can SFML or your code do anything about it? Most of the reported leaks that I have encountered running simple SFML examples come right out of the graphics driver, and when that happens the only thing you can do is ignore them.

The leaks that I care about in this instance are one-time leaks where something has been created but not deleted, but I'm sure it will extend to other types of leaks as I go along. As you say, it's not easy to do anything about the graphics driver leaks, so if I can't do anything about them I don't want to have them cluttering the output logs and masking 'real' leaks. In short, I only want to be notified about the leaks that I can do something about.

The second question that has to be asked is: why do you need a leak detector? I used to use leak detection tools a lot in the past, but these days, I've just gotten accustomed to writing code that has no way to leak at all. Trust me when I say the little bit of effort you put into doing that outweighs the effort you will spend in tracking down and eliminating leaks that happen to pop up. Modern C++ also provides standardized ways of avoiding potential sources of leaks all together. Back when I used to deal with leaks, such things were only provided in libraries or had to be written by oneself making it easier to just deal with the leaks when they happen. Modern C++ code has made leak detectors kind of obsolete, at least if it conforms to common practice. There are already so many posts on this forum that deal with coding style and memory management and even a section in the FAQ, hence I won't spend unneeded time copying and pasting what has already been said.

See my first response, basically those are my reasons for using old-school memory management. However I've taken a look at a little bit of documentation on smart pointers and the FAQ, I'm still not entirely convinced this is the way to go. I feel as though its the same as saying "why aren't you using C#, that would fix your memory leaks."

If you insist that your source of leaks are absolutely unavoidable or for some reason the cost of dealing with their source outweighs the effort needed to find and eliminate them, then you can check out valgrind if you have access to a Linux machine. In my opinion it is easier to find leaks on Linux machines because the tools are provided more and easier access to the data they need to instrument the execution of a binary better than say on Windows. If you are looking for state-of-the-art leak detection, get a working LLVM/clang toolchain and run its numerous sanitizers over your code/executable. I've yet to see a more performant suite of tools that offer the same amount of integration of static and dynamic analysis into the instrumentation (and on top of that, it's completely free).

I don't have a Linux machine unfortunately,  I will look into the code sanitizers though.

At this point I'm at unsure of what to do. I can say "overhead be damned" and use smart pointers, then worry about overhead when the problem occurs. The alternative doesn't look great, because I won't be able to track my memory management well with the driver leaks clogging up the system.

[eXpl0it3r]

If done right, there's no real overhead by using smart pointers. You're essential only making your life hardet by not sticking to modern C++.
You don't get "tighter" memory management through manually releasing memory, but you only make space for a lot of leaking possibilities, plus making your code less maintainable and less readable.

Nexus has written a good example on why RAII Rocks. Using modern C++ can indeed feel a bit like switching to a "new" language, especially if you look at all the C++11 features, but there's really no readon to get stuck in the past due to some "feelings", it's still C++ after all.

Also: You should not fear refactoring your code!

[binary1248]

See my first response, basically those are my reasons for using old-school memory management. However I've taken a look at a little bit of documentation on smart pointers and the FAQ, I'm still not entirely convinced this is the way to go. I feel as though its the same as saying "why aren't you using C#, that would fix your memory leaks."

If you compare using smart pointers to using C# then you haven't fully understood what smart pointers really are. C# uses managed memory and doesn't give the programmer any real power over how they want to manage their memory hence the term managed. Smart pointers in C++ is only about management of your memory. Don't get me wrong, there are still ways that you can cause leaks with them, however it is very very hard to do so and very unlikely to happen accidentally. I can't see how the two are related in any way short of "having something to do with memory management" in the most remote sense. If you ask me, C# took ideas from C++ and mixed them with everything that makes Java horrible to give Java programmers a reason to try out a new language. I wouldn't touch it even with a ten foot pole.

Using smart pointers doesn't mean you relinquish your power over allocation and deallocation. It merely means that allocation and deallocation of memory are bound to the lifetime of your object, which ties in with RAII. It makes sense that once you have signalled you have no more interest in "keeping an object alive" you get rid of all references to it. In that case the memory allocated for it is deallocated automatically as well. Using smart pointers and RAII lets you care about higher level semantics such as object lifetime without having to worry about lower level things like "are all objects that are referenced properly freed" and "is someone else referencing the object, if not I need to free memory".

Taking from your example, if you are making a simulation game where you need to clean up 100 dead enemies after a bloody battle you are likely to store them in some sort of container. If you use smart pointers for memory management, removing these dead enemies from the container will automatically release the memory that they own and that of any objects that are referenced by them. You don't want to delete them all at once? Move their owning smart pointer into another container for objects to be culled, and remove them over time from there at your own pace.

Like already said, smart pointers aren't really overhead (most of the time they get optimized to the same amount of code as manual memory management would produce and a negligible increase in memory consumption, depending on what kind of pointer you employ), and you have to try them out and embrace the idea behind them to fully understand what they are capable of. Glancing over them doesn't really work in this case. They were meant to solve real-world problems and the best way to understand how they can make your life easier is to actually use them in real code.

[DrEnzyme]

@binary1248

Thanks for the clarification. I'm wary of memory management after having to work with Flash for a decent length of time. Did you know that Flash doesn't deallocate memory when it goes out of scope? It's true. After you release all the references to an object it can just sit around in memory until flash gets bored and deallocates it. Or if there's a bug in the memory manager (it's Flash, so there always is), it'll just keep sticking stuff in the garbage collector and not disposing of it.

As I said, I'm going to give it a go. It would be stupid not to, and I already spent a substantial amount of time integrating SFML into my engine. I also got a couple of opinions from my game-dev friends, and one of them was pretty positive about the new pointers. When they change what 'it' is, you tend to get sceptical:



C# is an OK language in my opinion. It's good for getting things running fast (not efficiently fast, coding fast). I've used it when doing Unity stuff, and it seems to be a good fit for that particular thing. I think the main problem with C# is that because you don't need to worry about your news, you don't tend to learn the 'dos' and 'do nots' of memory. Like which objects should own other objects, or instancing.

If done right, there's no real overhead by using smart pointers. You're essential only making your life hardet by not sticking to modern C++

From what I've read, there is overhead involved, but it is magnified if you use the smart pointers wrong (especially with shared_ptr). In my head, as long as the overhead is minimal with respect to the gain you get from using smart pointers, I'll use them.

Also: You should not fear refactoring your code!

Oh, totally man. I've built my engine over about 5 years, refactoring as I go, fixing things, removing things, recoding the bits that don't work well. But there comes a point where you have to say, "I've spent too much time refactoring, I need to make a game" and I think I've hit that point with my engine.

[Nexus]

std::shared_ptr has a lot of overhead resulting from the thread-safe reference counter. But it's usually not to compare directly with new/delete, there is additional logic behind it. This smart pointer is only used if you need shared ownership, which happens very rarely. Don't misuse it as a GC.

std::unique_ptr has zero overhead. It only wraps a pointer and ensures to call delete when it is destroyed. It is this pointer you should use by default, it allows you to implement RAII.

In addition to the standard smart pointers, I have implemented aurora::CopiedPtr which employs deep-copy semantics through polymorphic class hierarchies. If you're interested, you can read more about it here.

[amir ramezani]

firstly, as binary 1234 sed, use smart pointers
secondly, use CPPCheck to see the memory leeks in functions
thirdly, use a debugger to debug your application
and forthly, don't manage the memory by the alloc, free, malloc and provided functions!
some searches on the google may help you to better manage your memory
read some articles, books and manage it!

[DrEnzyme]

firstly, as binary 1234 sed, use smart pointers
secondly, use CPPCheck to see the memory leeks in functions
thirdly, use a debugger to debug your application
and forthly, don't manage the memory by the alloc, free, malloc and provided functions!
some searches on the google may help you to better manage your memory
read some articles, books and manage it!

The leaks in question do not come from my code. I verified this by creating an sf::RenderWindow in a simple app (on the stack) and closing the program immediately afterwards. A _CRTDump and VLD report both returned leaks. From what I was told, these "leaks" are possibly cleaned up after the program exits, and are possibly a problem with the OpenGL driver, but I wasn't linked to any of the discussions about this, told how to fix it, or given any other information. I have tried searching for answers on google, I initially filed the problem as a GITHUB report, and I've asked here. Universally, people have told me to use smart pointers, but this doesn't actually solve the problem I'm having. I need to be able to see that the project-for all intents and purposes, a 'blank' project- isn't leaking memory.

You've all convinced me that smart pointers are useful. That's great! What I would ask at this point, is for solutions to the problem I have described.

[binary1248]

Graphics driver leaks are exotic in more ways than you might expect. They leak when they want to and don't when they don't feel like it. The fact that your blank project doesn't leak doesn't mean anything, it doesn't tax the graphics driver in any meaningful way. This is a known "problem", or artefact. We've learnt to live with it, and you should to, unless you want to sign up for a position on their driver development team.

[DrEnzyme]

The fact that your blank project doesn't leak doesn't mean anything, it doesn't tax the graphics driver in any meaningful way.

The blank project DOES leak memory, that's what I'm saying.

[binary1248]

http://en.sfml-dev.org/forums/index.php?topic=13568.0

Just a barebones example that creates and destroys an OpenGL context (not even involving SFML at all) will leak memory on my system. This is not something SFML can fix on its own.

[DrEnzyme]

Just a barebones example that creates and destroys an OpenGL context (not even involving SFML at all) will leak memory on my system. This is not something SFML can fix on its own.

You'd think the guys that wrote the drivers would test the damned things, it would literally take them an hour to set up a test project and run it once. At least this clarifies the problem somewhat. I'll try updating my drivers and I'll see if that reduces the number of leaks. After that, I'll just learn to live with them.

secondly, use CPPCheck to see the memory leeks in functions

I'm going to give this a go as it might help me isolate my project code from the leaky GL nonsense. This doesn't preclude me using RAII, but it's nice to have a leak detector as a safety net.

[amir ramezani]

as i mentioned before, debug your application!
it help's you  to better solve your problems (like memory leeks)
but you have to know some assembly