Messages

1

General / Re: What memory leak detector do you use?

« on: December 05, 2013, 02:22:04 am »

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.

2

General / Re: What memory leak detector do you use?

« on: December 04, 2013, 10:53:25 pm »

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.

3

General / Re: What memory leak detector do you use?

« on: December 04, 2013, 10:11:24 pm »

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.

4

General / Re: What memory leak detector do you use?

« on: December 03, 2013, 04:48:40 am »

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

5

General / Re: What memory leak detector do you use?

« on: December 02, 2013, 05:47:25 am »

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.

6

General / What memory leak detector do you use?

« on: December 02, 2013, 01:16:35 am »

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?