Weird memory issues.

vinicity

Hi,

I have been having problems in my game that the available memory keeps going down, I can see it when I have Fuze's monitoring overlay turned on. There is also an issue with not all memory being returned when restarting the game. These two issues eventually causes an memory allocation error when I start my program (after a long Fuze session with lots of program restarts).

I thought at first that the lost memory was due to me not freeing sprites or images correctly, but after investigating further, I'm not so sure. It seems more to be a case of going too deep into nested loops and if statements...

I have submitted a working copy of my game with ´lots of stuff commented out in order to illustrate the problem.

ID: LXK7UWHY2C
Title: Shmup 1 - Memory problems

Press A to start and after a few seconds you will notice that the memory goes down by about 30 MB. This memory is never returned, and eventually this will keep happening, causing the available memory to drop.

I have tried to locate where the issue happens: row 1119 calls a function called getFreeShotSprite(), and in that function I have commented out everything but a for loop and an if statement.

So here is what happens:

Start Fuze from scratch, and start my game. The memory counter reports that 1382 MB is free.
Press A, and memory goes down to 1254 MB. That might be a reasonable number since there are a lot of memory structures etc. being allocated.
Exit the game and restart it. This time the total memory is 1285, indicating that not all memory has been freed correctly.
Press A to start. This time again, the memory goes down to about 1253. Seems like it might be reasonable.
Exit the game. In the code editor, comment out lines 1679 and 1682 (just an empty for loop that should not affect memory consumption).
Running the game now, memory starts at 1283, but after commenting out the lines above, memory no longer goes down to 1253. It seems like an empty for loop consumed about 30 MB which was never returned? That can't be right.

Sorry for the long post. I tried to pinpoint the issue, but it is really hard.

joyrider3774

@vinicity i tested it while the 30 mb being used for this loop is weird. The memory does get released every time i ran it. i mean i get the 30 mb back on each restart. However it seems you also suffer from the same bug as i'm having being that you lose 1mb of memory every 2 times you run your application (game). I see the exact same thing and i think it's got something todo with images Loadimage. I also noticed that in theory you have to run my / your game 2000 times to lose 1 gb of starting memory but with my game during development this happens way quicker (i sometimes start with 700-800 mb of starting memory) and my guess is, but i have not been able to confirm it yet if a bug appears in your code where fuze displays an error sometimes the memory is not released. This is only a guess though as i only see it happening when i'm actually developping my game. so it could be your run into something similar but i don't see the 30 mb not being released with me it was always released but the 1 mb per 2 runs kept happening

vinicity

I have seen the error about "unable to allocate memory" once. I don't think I had the memory overlay on at that time, though.

Willpowered

There is also an issue with not all memory being returned when restarting the game.

In F4NS 3.0.0, the interpreter uses a pool for some internal resources, which are around 32MB each. These aren't cleaned up at the end of program execution, but rather reused on the next run. They're also reused during program execution. You may notice a lower available memory while running your games due to this, but it also increases speed. This system may change in a future version.

These two issues eventually causes an memory allocation error when I start my program (after a long Fuze session with lots of program restarts).

Possibly related to this issue: https://fuzearena.com/forum/topic/1598/actual-code-size-in-editor-is-affecting-available-memory-program-has-to-start-with-until-fuze-restart

Thanks for the report! I'm looking into the memory issues.