Detect memory leak with debugger/profiler ?

DaveInDev

Member
Hi there,

I wonder if there is a guaranteed method to test if your program has some memory leaks ?
I thought about stopping the debugger at some choosen game start event (before any allocation), engaging the profiler, playing a few levels, and stop the debugger again at some game end event, and try to see if the RAM usage is the same at both points... But I do not succeed in showing this RAM usage (the RAM graph does not seem to go down at the end of my program. So I wonder how can I do this start/end RAM comparison (that I was used to do under Visual studio C++), in which event, using which RAM indicator ?
 

DaveInDev

Member
No idea ?
I wonder at least how do you use the RAM graph of the profiler. Just as an overall indicator ? No way to precisely monitor the RAM usage ?
 
There's not really a guaranteed way to test for memory leaks. It's difficult if not impossible for the debugger to tell apart a memory leak from intentionally allocated memory. The best way to check for memory leaks is to do it yourself with something to monitor memory usage. Thankfully, GM has a nice graph.

This is probably a memory leak...

You don't even have to run it with the profiler; it's always on. Green line is RAM. It's normal for memory usage to go up slowly as things change and new resources and instances are loaded in, but if it's constantly going up at an above-glacial pace and never going down even after running for a long time, you likely have done something to cause a memory leak.
 

DaveInDev

Member
but if it's constantly going up at an above-glacial pace and never going down even after running for a long time, you likely have done something to cause a memory leak.
:D yes, I already use this method, but it's not very precise, as the RAM graph is always fluctuating a little bit.

what do you mean by " do it yourself with something to monitor memory usage " ? Is there some function in GMS2 that return RAM usage or similar information, so that I can save memory snapshots ?

For memory leaks in VC++, I was taking a snapshot of memory with the profiler at the very beginning of the program before any memory allocation. And then a snapshot just before quitting the game, after every deallocation. If no memory leak, both snapshots were the same. If not, I could even find out which pointers were still "alive" and have a clue on my error.
 
:D yes, I already use this method, but it's not very precise, as the RAM graph is always fluctuating a little bit.

what do you mean by " do it yourself with something to monitor memory usage " ? Is there some function in GMS2 that return RAM usage or similar information, so that I can save memory snapshots ?
I was just referring to the graph.

For memory leaks in VC++, I was taking a snapshot of memory with the profiler at the very beginning of the program before any memory allocation. And then a snapshot just before quitting the game, after every deallocation. If no memory leak, both snapshots were the same. If not, I could even find out which pointers were still "alive" and have a clue on my error.
There's no function or anything that exposes whether something is allocated or not to the user. GM handles memory allocation and deallocation behind the scenes, and GML is nowhere near as low-level as C++. By its very nature, it's going to be more wasteful and therefore strictly managing memory is not quite as important. That's why directly analyzing your memory usage is important if you think there's an issue. It's normal for it to go up slightly over time. If it's going up consistently with no input from the player or no new instances being created or resources being loaded, then you have a serious problem. It's relatively easy to spot problems since there are generally only a few areas where memory leaks can pop up, and few functions than can cause them. Almost all of them dealing with dynamic data.
  • Data structures
  • Dynamic resource creation (e.g. loading sprites or music)
  • Surfaces
  • Buffers
  • Structs
  • Particle systems
  • Audio emitters
  • Vertex formats
  • Disabling garbage collection with gc_enable(false) and never collecting it
Very likely, you're using very few of those, if any. It's very easy to stress-test particular instances where you're using functions related to creating those dynamic data types and figure out what's causing you trouble.
 

Chourando

Member
There's a good solution from YellowAfterlife for tracking memory leaks of DS. It's called Quality Structures. It saves me lot from memory leaks caused by DS. And for memory tracking I use external memory tracker, there's few in marketplace. Quite handy.
 
There's a good solution from YellowAfterlife for tracking memory leaks of DS. It's called Quality Structures. It saves me lot from memory leaks caused by DS.
Useful, but it's a bit outdated after 2.3. ds_maps are effectively replaced by structs, which have a lot more functionality. Arrays took virtually all the useful functions from ds_lists and everything useful from ds_stacks, making arrays (which are garbage collected) far more flexibile and leaving the latter two near-pointless. Structs can leak but aren't caught by Quality Structures.
 
Top