• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Making room persistent and then not persistent is causing memory leak

Zuljaras

Member
I decided to make a new thread since the other one is not about his issue.

So my pause menu (inventory etc.) is in another separate room (not persistent).

When I am in the game and decide to go there I press my "A" key I set my current room persistent = true and them I go to my pause menu.
After going back I set the persistent = false.
So far so good!!! It runs perfectly in GMS 1.4.

However in GMS 2 every time I do that I get memory piling up! if I do not make the current room persistent there is no memory leak!

Is there something I am missing?!

Here is the control object that handles the whole thing:
Code:
Information about object: controlobjectpausemenu
Sprite:
Solid: false
Visible: false
Depth: 0
Persistent: true
Parent:
Children:
Mask:

No Physics Object
Create Event:

execute code:

global.lastroom=1;
canpress=true;


Alarm Event for alarm 0:

execute code:

audio_pause_all();
room_goto(pausemenu);
canpress=true;

Alarm Event for alarm 1:

execute code:

audio_pause_all();
room_goto(shop_room);
canpress=true;

Alarm Event for alarm 2:

execute code:

audio_pause_all();
room_goto(map_room);
canpress=true;

Step Event:

execute code:

if instance_number(object_index)>1 instance_destroy()

if room!=pausemenu && room!=shop_room && room!=map_room
{
if (keyboard_check_pressed(global.KeyDefault[3]) || gamepad_button_check_pressed(global.gp,gp_padu) || gamepad_axis_value(global.gp,gp_axislv)<0)
{
if instance_exists(player_parent_obj)
{
if global.canshop=true && (playero.sprite_index=playersleft or playero.sprite_index=playersright)
{
if global.paused=false && canpress=true
{
if instance_exists(weapon_parent)
{weapon_parent.persistent=false;}
player_parent_obj.persistent=false;
new_resolution.persistent = false;
global.lastroom=room;
room_persistent=true;
canpress=false;
alarm[1]=5;
}
}
}
}

if (keyboard_check_pressed(global.KeyDefault[6]) || gamepad_button_check_pressed(global.gp,gp_start))
{if instance_exists(player_parent_obj)
{
if global.paused=false && canpress=true
{
global.lastroom = room;
player_parent_obj.persistent = false;
new_resolution.persistent = false;
room_persistent = true;
if instance_exists(weapon_parent)
{weapon_parent.persistent = false;}
canpress=false;
alarm[0]=5;
}
}
}

/*
if os_is_paused()
{
if instance_exists(player_parent_obj)
{
if global.paused=false && canpress=true
{
if instance_exists(weapon_parent)
{weapon_parent.persistent=false;}
player_parent_obj.persistent=false;
global.lastroom=room;
room_persistent=true;
canpress=false;
alarm[0]=5;
}
}
}
*/

if (keyboard_check_pressed(global.KeyDefault[10]) || gamepad_button_check_pressed(global.gp,gp_select))
{if instance_exists(player_parent_obj)
{
if global.paused=false && canpress=true
{
if instance_exists(weapon_parent)
{weapon_parent.persistent=false;}
player_parent_obj.persistent=false;
global.lastroom=room;
room_persistent=true;
canpress=false;
alarm[2]=5;
}
}
}
}

Other Event: Room Start:

execute code:

if room!=pausemenu && room!=shop_room && room!=map_room
{
player_parent_obj.persistent = true;
new_resolution.persistent = true;
if instance_exists(weapon_parent)
{weapon_parent.persistent=true}
room_persistent=false;
}
I personally think this is bug in GMS 2.
 

Zuljaras

Member
I have filed a bug and waiting to see what YoYo have to say.

In the meantime if anyone know more on the subject please do share some info :)
 

Zuljaras

Member
I did a small file just for the bug report and the same thing happens thee as well.

I hope I am not in the wrong here because I thought that if I make a room persistent THEN go to another room, come back and make the room NOT persistent again that should free it from the memory right?
 

Zuljaras

Member
Bump.
I am still waiting on response from the YoYo QA staff.
However if anyone know more on the subject please share.
 

Zuljaras

Member
I have tried couple of things:

1. If I put room_persistent = false in the Step event it works just fine but the room is not persistent so it is just for debugging purposes.

2. I think it is only this room_persistent that is NOT working in the Room Start event.

I wonder if I should post this is the advanced programing forum.
 
Last edited:

Zuljaras

Member
Hello again and again!

I am a little frustrated by this issue and I do not know if the results will be the same for others. So here are 2 extremely small example projects that are absolutely the same. One is in GMS2 and the other is in GMS1.4.

I have movement between 2 rooms. When I go to one I make the current one persistent after I get back to that room I make it NOT persistent. Really simple design.

However every time I go back to the previous room and make it NOT persistent memory is accumulated EACH time.
The same thing is NOT happening in GMS1.4.

So does GMS2 works differently or this is a bug?

I am attaching the 2 examples.

https://drive.google.com/file/d/1UG4AWf7CO1FWrGsvBo2WjLcKIbyBWWes/view?usp=sharing

https://drive.google.com/file/d/1nBnsnP7hxBIoeWspWfSP2mzI57oY170J/view?usp=sharing


Any info on the matter is greatly appreciated!
 

TsukaYuriko

☄️
Forum Staff
Moderator
Before we can attempt to suggest solutions, we first have to make sure that you, in fact, have a memory leak.

To verify this, repeat the action you deem to cause a memory leak infinitely. Does your game ever crash with an "out of memory" error?

If yes, you have a memory leak.
If no, you definitely don't have a memory leak.

Memory usage rising for a few iterations and then stagnating is nothing to worry about, as some data may be cached and kept in memory, or freed but not released (and then later re-used).
 

Zuljaras

Member
Before we can attempt to suggest solutions, we first have to make sure that you, in fact, have a memory leak.

To verify this, repeat the action you deem to cause a memory leak infinitely. Does your game ever crash with an "out of memory" error?

If yes, you have a memory leak.
If no, you definitely don't have a memory leak.

Memory usage rising for a few iterations and then stagnating is nothing to worry about, as some data may be cached and kept in memory, or freed but not released (and then later re-used).
I made it by pressing the same button to change rooms. I would make it so it changes them on its own. Pretty sure it will crash the project.
 
T

Taddio

Guest
GMS 1 didn't had the Clean Up event, you need to use that to destroy your lists in GMS2. I suggest you check if every ds/path/surface exists and clear them in CleanUp. Also, do you have lists/grids of lists/grids?
 

Zuljaras

Member
GMS 1 didn't had the Clean Up event, you need to use that to destroy your lists in GMS2. I suggest you check if every ds/path/surface exists and clear them in CleanUp. Also, do you have lists/grids of lists/grids?
Only one surface and ds lists. But I know how to clean them. Also IN the test projects attached to the thread there are zero surfaces, lists or anything like that. The issue is purely in GMS 2.
 
You said that you're pretty sure that changing the room constantly will crash the room. Are you sure, or just assuming? If you keep changing the room, does it consistently rise, or did you try it only a few times before coming to a conclusion?
 

chance

predictably random
Forum Staff
Moderator
I believe this is a bug in Studio 2.

I did a simple test with two empty rooms, and one controller object that changes rooms when a key is pressed. No other objects, data structures, etc.

If either (or both) rooms are "persistent", the debugger shows an abrupt increase in memory usage when the room changes. It's an increase of about 200 KB each time when moving from one room to another.

Once in that room, the memory usage levels off. But it increases again each time you change rooms.
 

Zuljaras

Member
I believe this is a bug in Studio 2.

I did a simple test with two empty rooms, and one controller object that changes rooms when a key is pressed. No other objects, data structures, etc.

If either (or both) rooms are "persistent", the debugger shows an abrupt increase in memory usage when the room changes. It's an increase of about 200 KB each time when moving from one room to another.

Once in that room, the memory usage levels off. But it increases again each time you change rooms.
Exactly!
Just made the test that TsukaYuriko suggested. GMS2 crashed in 4-5 seconds and GMS1.4 is doing just fine with no memory issues.

Reported the bug and waiting for YoYo response!
 

Zuljaras

Member
You said that you're pretty sure that changing the room constantly will crash the room. Are you sure, or just assuming? If you keep changing the room, does it consistently rise, or did you try it only a few times before coming to a conclusion?
Tried the suggestions by the moderator and it is indeed bug in GMS2.
 

chance

predictably random
Forum Staff
Moderator
(Topic moved here to tech support.)

Seeing this topic today gave me a little twinge of guilt. Because I noticed the leak many weeks ago while working on a project with another member (@MissingNo.). He urged me to file a bug report... but I never followed through. I just worked around the problem and forgot about it. Shame on me. :(
 
Last edited:

Zuljaras

Member
(Topic moved here to tech support.)

Seeing this topic today gave me a little twinge of guilt. Because I noticed the leak many weeks ago while working on a project with another member (@MissingNo.). He urged me to file a bug report... but I never followed through. I just worked around the problem and forgot about it. Shame on me. :(
I will update the thread once the bug is confirmed because now it is in status opened.

However to be honest I reported it 15 days ago but I did not get confirmation of it yet because of that I thought I did something wrong.
The comparison of GMS1.4 and GMS2 confirmed it to be a bug after all.
 

MissingNo.

Member
Seeing this topic today gave me a little twinge of guilt. Because I noticed the leak many weeks ago while working on a project with another member (@MissingNo.). He urged me to file a bug report... but I never followed through. I just worked around the problem and forgot about it. Shame on me. :(
Haha don't feel bad, it all worked out in the end.

Zuljaras in your report did you link them to this thread so that they can see the other members confirm this bug? That would be good to give them something extra to look at if needed.
 

Zuljaras

Member
Haha don't feel bad, it all worked out in the end.

Zuljaras in your report did you link them to this thread so that they can see the other members confirm this bug? That would be good to give them something extra to look at if needed.
I just did.

Also a funny thing is that 2 years ago I reported the same memory leak but it was happening with normal NON-persistent rooms.
They fixed it. But here we are again with persistent rooms :(
 

Zuljaras

Member
So they never replied? Well they will eventually, in my case they replied within a week.
They replied only one time to ask me to make smaller sample of the bug. That was 2 weeks ago.
Since then, nothing.

They also told me that this is probably my coding issue since the bug is only reported from me.
That is also one more reason to attach this thread to the bug report as suggested from the other users here.
 
S

Sam (Deleted User)

Guest
I really hope they take this issue more seriously. I've been hearing about it for quite a while.
 

MissingNo.

Member
They replied only one time to ask me to make smaller sample of the bug. That was 2 weeks ago.
Since then, nothing.

They also told me that this is probably my coding issue since the bug is only reported from me.
That is also one more reason to attach this thread to the bug report as suggested from the other users here.
Did you reply to them and tell them other users have this problem and to check out this thread?

Even forum Moderator chance confirmed this is an issue so this can't be a coincidence. And he is no slouch when it comes to coding.
 

chance

predictably random
Forum Staff
Moderator
Yep. I linked this thread in the bug report.
Probably a good idea... but I'm also concerned it may cause confusion. Because the memory leak doesn't require "making room persistent and then non-persistent". And it doesn't require any code to create it.

The leak occurs simply by moving in or out of a persistent room. It's not necessary to toggle the persistent flag to create the leak.
 
S

Sam (Deleted User)

Guest
Probably a good idea... but I'm also concerned it may cause confusion. Because the memory leak doesn't require "making room persistent and then non-persistent". And it doesn't require any code to create it.

The leak occurs simply by moving in or out of a persistent room. It's not necessary to toggle the persistent flag to create the leak.
This is probably why they aren't looking into it as much it wouldn't surprise me.
 

Zuljaras

Member
This is probably why they aren't looking into it as much it wouldn't surprise me.
Well they could just tell me so instead of ignoring the issue because when I reported it a second time on the next day there was a response.
I do not think they have any excuse on the matter.

If anyone report the issue please post here so I could track if it is fixed.
 
This is probably why they aren't looking into it as much it wouldn't surprise me.
Total speculation.
Well they could just tell me so instead of ignoring the issue because when I reported it a second time on the next day there was a response.
I do not think they have any excuse on the matter.
They may be looking at it. Don't take the word of anyone here that is not a YYG staff member as nobody else will know exactly what is going on with a bug report. It may show that it has been looked at 14 days ago, but that does not mean that it is not currently being worked on (or even in QA or something for testing) - we just don't know.
 

MissingNo.

Member
It may show that it has been looked at 14 days ago, but that does not mean that it is not currently being worked on (or even in QA or something for testing) - we just don't know.
Well if they are working on the bug it would be listed in the Mantis tracker, they wouldn't be fixing a bug not listed in the Mantis tracker. And they already replied saying
they needed a smaller sample of the bug because they had trouble reproducing the issue. So that combined with the fact that @chance said that @Zuljaras accidentally gave
some wrong information probably means this issue isn't being looked at any further until they see his replies.

Also they have loads of issues they are currently dealing with on the tracker, they wouldn't be spending 14 plus days looking for a bug that they don't know exists.
The burden of proof is on the users to prove this bug exists. They would have followed the steps given by @Zuljaras and did a few other tests and then moved on to something else.

So I highly doubt they are either in the process of fixing the bug or tracking the issue down.
The bug would be listed in the tracker if they were going to fix it. Also they wouldn't be spending days looking for a bug they don't know exists.
They are only going to look at this again when they look a his replies or get another ticket for the same bug.
 
Last edited:
  • Like
Reactions: Dan

Zuljaras

Member
Could someone else report the bug? I am not getting any response from the YoYo staff. This is not ok no matter how much work they have.
The issue was created April 09, 2019.
 
Top