WTF is a memory leak in Godot?

right so i think everybody's pretty familiar with the basics of memory management in godot you add stuff to the scene tree and then we call cue free how do you know that you're not leaking memory well in godot we have this monitor and it tells us our memory static dynamic more importantly it tells you the object and node count so you can see here we have 106 nodes because i have added 106 sprites and i'm going to click cube free on the big green square and remember in case you forget you only have to call q free on the parent and then all its children will be free so let's call q free and we've five notes now okay no memory leaked okay this time we're going to try creating memory leak so i'm going to call remove child on the green parent now let's look at our monitors here okay now we have orphan nodes so you might be thinking ah that's why i know there's a memory like orphan notes no because if i now change the scene we'll reload the scene or if the notes have gone to zero why because if we look at the code for remove child here this button what i was doing was i was taking into a variable the node green square i was removing it and then when we exited the tree when i changed the scene that was we're going to free it and that's why it got rid of the orphan notes so orphan nodes are not bad it's just the debugger trying to be helpful but if i were to delete this code here delete this line here now when we run the program we go to our monitors click remove child we have now 101 orphan nodes i'm going to reload the scene we still have 101 orphan nodes and you can see here we're leaking memory and we call it a leak because we can't free this memory like it's impossible there's no way to find these objects and free them now it's just gone program is corrupt forever until we restart the program so maybe you're sitting there saying well i use q3 so i don't have memory leaks well there's a lot of white league memory and though here's a pretty advanced example i have this class called actor and it extends reference and has one member friend and remember references are those magic objects that are supposed to free themselves and how they do that is actually just under the hood it just keeps a little integer going up and down as you copy it and when the integer goes down that means there's no more copies of it and it just deletes itself that mechanism is great but it has a flaw so i'm gonna create this guy called homer and this guy called lenny when i create homer homer is a new reference a new actor and he has a ref count of one so under the hud here there's an integer there's a number saying there is one of homer and then we're going to create lenny and the same thing under the hood it's going to say there is one lenny next i'm going to say homer's friend is lenny and that's going to increase lenny's ref count to two so under the hood now lenny says oh there's two of me and then we do the same thing for homer so now homer's ref count is two once we get here homer goes out of scope homer's ref count goes down one because he's going out of scope so kato says oh there's one less of you so that leaves us now with homer's ref count being one and lenny's ref count being two so then next stop then goes out of scope now lenny's ref count goes down by one so now we're left with lenny's ref count as one and homer's ref count is one and now we've leaked these guys we no longer have access to them so that's a pretty nasty memory leak we can see that our objects are just going up and up and up and up so to fix this it's really easy we just wrap lenny in weak ref and homer in weak graph and what this does is it just tells godot this is a reference but don't actually increase its account so after using weak graph this would be the flow we would end up with zero ref counts and you can see here we are not leaking objects so i'm showing you this example not to say oh this is a memory leak you have to look out for what i'm saying is that there's tons of ways to leak memory so just be careful and always look at your object monitors so that was the main example right but let's look at a real world example this morning i discovered that in the in-game editor of space bound at the game i'm making that there's a memory leak and how did i know that well if we go to my monitors we can see here that the main menu which i kind of consider the staple state i always know that it has this many objects in it exactly this many objects i should say right except this object hand here this goes to 1209 but that's that's fine and i know why that that one extra object is there and i went into the editor we're going to add a gun and then we're going to quit and the object ends didn't go back down to normal because resources should have been 127 objects should have been 1209 so i'm leaking not nodes but i know that i'm leaking an object or a reference so identifying you've memory leaks is super easy to do just these monitors don't go back down so how do i find the memory leak though because there's like a thousand lines of code between the main menu and the action of adding that gun so do i have to check every single line uh no and what we can do is we can buy and research the stack if you think about it like this okay when we launch the main menu till time where we add the gun a bunch of functions get called and we can see that in the call stack in our debugger so if i'm to go to the editor script and i go to add entity which i know is the function that adds the gun and i go to my editor we're going to add a gun and now we see in our call stack we have these functions right there's probably a few hundred lines of code and all these functions but i don't want to check off what i want to do instead is i want to jump halfway so i'm going to check halfway down the stack so that would be let's say paint and in this function i'm then going to again halfway just divide it in two i'm just gonna abort just do an early return like this so what i'm saying is jump halfway then just don't run any of this code make sure that it doesn't happen and then we're going to see do we have the memory leak after this is run because that way we've actually cut off half of the code we need to check right i'm going to add this gun it didn't add right because i deleted all that code i uncommented all that commented out all that excuse me now let's check our memory counters and it's fine so i know that the line must be after this which is great right that means here i've eliminated like half of the code that i need to check i didn't have to check every single line and then we just repeat that right just a binary stretch and then we jump halfway again that's what you would do if you had a lot of code but thing is i just saw a glimpse of the code there but i know exactly what i've done wrong remember when i said that there's that one extra object that i don't have to worry about that's the problem so i guess i've i've taught myself and you uh a lesson here which is that if there's ever a part of the code you think oh no no no there's no memory leaks in that no way that's the super smart part that i wrote um it's most likely where it is so what's happening is that in my code we have an undo but it's an object when i add stuff right let's say i have these walls and then i hit ctrl z and then i hit ctrl shift set it's redoing it and it's only able to redo it because i give the undo stack the object a copy of it and say oh by the way if i undo add this thing back in and because it's an object and not a reference or a node i was forgetting to free it on exit tree so all i do to fix this is go to my editor and on exit tree we don't actually want to free the undo stack you can't free the undo stack it's a weird object what we can do is call clear history so let's check if that fixes it we go to our monitors we have 1209 objects 127 resources we're going to add this gun and we're going to call quit and we have the same amount of objects awesome yeah so that's memory leaks in good though and if you want to support me please wishlist my gaming spacebandit a link to the steam page is in the description

Channel: samsface

Views: 3,495

Keywords:

Id: U6zHnNffnGE

Length: 6min 40sec (400 seconds)

Published: Wed Sep 08 2021

Reddit Comments

[u/AllenKll]

This guys youtube is GOLD. I suggest you all sub. His discord is kinda quiet, but friendly too!

[u/lvlgd]

Here was my experience with memory leek in Godot last year
https://www.youtube.com/watch?v=Pjivz\_3BQZo

[u/DaisyGamesStudio]

Not sure what's worse, memory leak or the edible one.

[u/dogman_35]

That title sounds like a threat lol

[u/SouthernWerewolf]

Gold content! Accurate and concise as all video tutorials should have been.

[u/tomeyro]

Thank you so much for this video!

I was thinking "oh I'm so smart doing this" and never thought about checking the monitors.

I was leaving ~10k orphan nodes every time I re-started the game scene because I removed them from the tree but never freed them. That was about 50MB of memory that got leaked every time I restarted a level.

Fixed now! :)