Possible memory leak?

This happens often when attempting to drag events, leaving me no choice except to close GDevelop and lose work. Usually it happens while trying to move only a single line within a block of events. There’s no “not responding” message or any indication of a crash other than being unable to do anything like click scene tabs, select other events, etc.

If I try to open the file menu to ‘save as’, the dropdown works, but it doesn’t open the folder. The only thing that does work is the “X” to close the program. Auto-save isn’t a solution since I’m not necessarily previewing after every change. :slightly_frowning_face:

memoryleak

3 Likes

Same problem for me, it’s happen rarely to me, honestly only on long session of GD.

Maybe a missing function for clear space in memory when in the eventsheet code.
I heard @4ian talk about an array of memory in LLVM (16mb by default) created by emscriptem for manage the data structure of GD in background.

Maybe this memory is full because lot of datas are manipuled overtime during long sessions witht GD.

This is not a new problem. It’s knowed, but this bug is not reproducable, so hard to catch for studie it :expressionless:

3 Likes

Sorry, I hadn’t realized it was a known issue - there didn’t seem to be any existing topics here about it and nothing recent on Github (unless I missed it). Thank you for the info and I should add that, yes indeed, it generally occurs when I’ve been in a long GD session too.

What you can do is see if there is a series of step that you can do that greatly increase the memory usage (like “Click there, create an object, do that, move that, then do it again and you’ll see that memory is increasing by 20MB each time, reaching 1GB after just doing that for 5 minutes”).
That could help finding something where there is a memory leak.

EDIT: side note about the “Emscripten” memory - it’s not a problem per se, if there is a memory leak in the native code ran by Emscripten (or soon in WebAssembly) or in JavaScript that’s the same. The only difference is that a memory leak in JS might be a bit easier to track thanks to the Chrome Debugger tools.

1 Like

Some testing I did recently:

  • I used two nested repeat loops to create a million variables. When loading the debugger, GDevelop crashed saying there was some limit of 2^52 or 2^53.
  • I then lowered to 100k variables. When I tried to display them in the debugger, it took some time and RAM usage went up to 4GB. I was able to view them after a couple of minutes.
    And I noticed that when I closed the project (not GDevelop), RAM usage did not go down. Not sure if it’s that’s a “memory leak”. :man_shrugging:

Not sure if a memory leak could cause that but that’s a really weird issue since the is should free all the memory of the process.

A memory leak is when you create a variable and forget to explicitly delete it. Let’s say you have some code creating a temporary variable. What will happen is that your program will ask the OS if it can have some ram for storing data (the variable). The OS then either say no or give some, and when you are done with the variable you delete it, Wich will result in clearing that bit of RAM and telling the OS “ok I’m done you can use that for something else”. A memory leak is when you never delete the variable. You may not even know that it still exists but it does. The problem is that if you keep on using the thing with memory leak is that the memory is never returned and cannot be reused even tho that memory is unused until the OS refuses to give any more memory (because there is probably none left)

1 Like

As for me, my ram gets filled up and windows slowing down after doing multiple undoing when i editing sprites