memory leak in function

[Luto]

i want to report a memory leak in function font_sprite_add_ext()

////CONTROL OBJECT
//create event
global.tlfont=0;
global.tlfont=font_add_sprite_ext(sprite3, "abcde" , false, 2); // my sprite3 have 5 subimages of 32x32 size

//key pressed A event
font_delete(global.tlfont);
global.tlfont=0;
game_restart(); // game_restart or room_restart the memory leak always stay

NOTE: if you check the global.tlfont variable with the debugger, it always add +1 in every restart of the game
NOTE: in three restarts i see that the memory leak is 0.37K is nothing but still it is a memory leak.
NOTE: try to add function draw_texture_flush(); and surface_free(application_surface); not work

try to add function font_delete in the create event but still not work:

//create event
global.tlfont=0;
if font_exists(global.tlfont)
{
font_delete(global.tlfont);
global.tlfont=0;
}
global.tlfont=font_add_sprite_ext(sprite3, "abcde" , false, 2); // my sprite3 have 5 subimages of 32x32 size

NOTE: "sorry for possible errors in the sintaxis i not have game maker studio in this pc to check for errors."

 

[obscene]

So you are checking to see if a font indexed 0 exists?

Hint: It don't!

 

[ParodyKnaveBob]

Howdy, Luno,

Have you tried this test without room_restart() or game_restart()? Last I checked, those two functions were acknowledged to leak memory.

I hope this helps,
Bob

 

[Luto]

Howdy, Luno,

Have you tried this test without room_restart() or game_restart()? Last I checked, those two functions were acknowledged to leak memory.

I hope this helps,
Bob

Hi ParodyKnaveBob

if i erase the line code of game_restart. would not have sense. the problem would persist and we would have a bad function that apparently it affects other elements as the global variables in my case.

now, as your you say my problem could be the restart_game or room_restart function because i saw a thread of the user Andrey and he upload a video showing a memory leak in that function. maybe something linked with these functions that does that my variable adds 1 in the restart.

https://forum.yoyogames.com/index.p...lem-with-memory-leak-on-1760.6569/#post-62909

the font is successfully deleted, but in the restart of the game, something adds +1 to the variable. and this happen every time that you restart the game or the room. in the debugger looks like:

variable | value
global.tlfont 0

then in the restart, the font is successfully deleted but the variable now adds +1

variable | value
global.tlfont 1

and again and again

variable | value
global.tlfont 2

variable | value
global.tlfont 3........................... 928347892347........ infinite............god...............super god......... universe destroyed

 

[Luto]

So you are checking to see if a font indexed 0 exists?

Hint: It don't!

hi obsdene

no, my problem is that in every restart of the game something adds 1 to my global variable that previously was containing the font. no matter everything that i do. it adds +1 in the restart.

 

[RangerX]

Redo your tests without using the "room_restart" or "game_restart" functions. Like a previous poster said, those functions are notorious for having problems/leaks. They are there more for early debug of your game than to be used in an alpha or beta version. Restart the game by you own mean to be sure that sprite_add function does what you think it does.

 

[Luto]

Redo your tests without using the "room_restart" or "game_restart" functions. Like a previous poster said, those functions are notorious for having problems/leaks. They are there more for early debug of your game than to be used in an alpha or beta version. Restart the game by you own mean to be sure that sprite_add function does what you think it does.

hi RangerX

ok i will do. also i will test with room_goto and room_goto_next to check if the issue persist.

 

[Luto]

i tested without restart function. and the problem persist when i return to my first room.

the plan was create 2 rooms and go from the first to the second and return to the first. checking at the same time possible changes in the font variable.

////CONTROL OBJECT (persistent)
//create event
global.font=0

//room start event
var r=0;
r=room_get_name(room);
if (r=="room_1")
{
global.font=font_add_sprite_ext(font_test, "abcde" , true, 2 );
}

//keyboard press A-key event
if font_exists(global.font)
{
font_delete(global.font);
global.font=0;
}
var r=0;
r=room_get_name(room);
if (r=="room_1")
{
global.font=0;
room_goto(room_2);
} else {
global.font=0;
room_goto(room_1);
}

the result was that in the room_2 the font variable not adds 1, BUT if i return from room_2 to room_1 the font variable adds +1 again!!!!! WTF!!!! and again and again and again!! wtf is going here XDDDD

this happen:

+room1
-global.font = font_add_sprite_ext(); // i can see in the debugger that the font variable is zero.
-i press "A" and the font is deleted and i set the font variable to 0
-i set global.font=0 again and i go to the room_2

+room2
-global.font is zero because this is not the room_1 and i can see his zero value in the debugger is correctly
-the font not exist and for that i not delete nothing
-i set global.font=0 again and i go to the room_1

+room1
-global.font = font_add_sprite_ext(); //THE FONT VARIABLE IS 1!!!???
-i press "A" and the font is deleted and i set the font variable to 0
-i set global.font=0 again and i go to the room_2

+room2
-global.font is zero because is not the room_1 and i can see his zero value in the debugger is correctly............ weird
-the font not exist and for that i not delete nothing
-i set global.font=0 again and i go to the room_1

+room1
-global.font = font_add_sprite_ext(); //NOW THE FONT VARIABLE IS 2!!!??? WTF!!
-i press "A" and the font is deleted and i set the font variable to 0
-i set global.font=0 again and i go to the room_2

in less words i see this in the debugger:
global.font = 0 - 0 - 1 - 0 - 2 - 0 - 3 - 0 - 4 - 0 - 5 - 0 - 6 - 0 - 7 - 0 - 8 - 0 - 9 - 0 - 10 - 0 - 11 - 0 - 12 - 0 - 13 - 0 - 14 .......................... infinite again =(

how supposed that I am going to do a good rpg with this problem =(

i really think that game maker have a really really big trouble here =(

 

[jackhigh24]

its not just room restart and room end its also room goto room next room previous, they all give the same memory leak of 3k, mike said or someone from staff said it due to not giving it enough time to clear when testing, so that means if we do a test and switch between room fast or restart then that 3k does not get cleared, think they said 3 or a few more steps should be good to clear it, but iv tested upto 50 steps and it will still build up, not tested past that to see if its will always keep building up.

 

[obscene]

I could be wrong but we are talking about two entirely different issues here. My entire point was this code is flawed from the start...

//create event
global.tlfont=0;
if font_exists(global.tlfont) // Well of course it doesn't, you JUST set it to 0 how could it possibly be an index to a font?

You need to be deleting your font at the end of your game or whenever you are done using it, not at the beginning.

 

[ParodyKnaveBob]

Also, Luno, you seem to be under the impression that every time you delete a dynamically added resource, you're guaranteed to recover its index for future use in similar resources.

Create something, get index 0.
Delete it, index 0 is still reserved* to help avoid conflicts.
Create something similar, get index 1.

That's a design choice -- not a bug. Is this what you're having trouble with?
(*At some point I believe data structures started reusing indices and still do,[citation needed] but I haven't looked into other resources, like the tree assets.)

I hope this helps,
Bob

 

[Luto]

I could be wrong but we are talking about two entirely different issues here. My entire point was this code is flawed from the start...

//create event
global.tlfont=0;
if font_exists(global.tlfont) // Well of course it doesn't, you JUST set it to 0 how could it possibly be an index to a font?

You need to be deleting your font at the end of your game or whenever you are done using it, not at the beginning.

No, you need understand the logic of the code that i posted in the beginning, that line of code that you say is an extra line code that i wrote in my despair but the line code that delete the font is still in the end. check the first post slowly

 

[Luto]

Also, Luno, you seem to be under the impression that every time you delete a dynamically added resource, you're guaranteed to recover its index for future use in similar resources.

Create something, get index 0.
Delete it, index 0 is still reserved* to help avoid conflicts.
Create something similar, get index 1.

That's a design choice -- not a bug. Is this what you're having trouble with?
(*At some point I believe data structures started reusing indices and still do,[citation needed] but I haven't looked into other resources, like the tree assets.)

I hope this helps,
Bob

I downloaded bandicam to record my screen. look:

the font is deleted yes, but when i return from room_2 to room_1 the variabla global.font adds +1

 

[obscene]

Sorry about that, when I see a line like that I become fixated on it... didn't notice the A key event.

 

[ParodyKnaveBob]

Luno,

Thank you for your thorough demonstration of the issue. That was pretty great, and I appreciate it. $:^ ]

1. The global.font variable is acting exactly as expected, exactly as designed, and exactly as I described up above: Every time you use one of the font_add*() functions (much like functions to dynamically add other assets), your new font gets an index added to by 1 (compared to the previous asset of the same type) in order to avoid conflicts with previously created resources -- whether or not the previous ones have been deleted. (This way, you can still test the old one for deletion while testing the new one for existence. If it stayed the same, your old destroyed ones would test positive for existing -- whoops, not good.) Then, every time your particular coding uses said function, it's assigning that newly created index to the same variable. This way, global.font keeps getting a new value assigned to it every time you create a font. (That's no leak. The numbers 0, 4294967296, and -3.1415926535897932384626433832795 all take the same amount of space assigned in GM's real variables -- technically, "floating point doubles.")
2. Since you're still going between rooms, and @jackhigh24 sends the alert that all room-changing functions are acknowledged as tiny memory leaks, your test is still not controlled. Try creating and destroying fonts in conjunction with nothing but keypresses -- not even instance creation/destruction; too, try going between rooms without modifying anything else. See what those tests garner for you.

Again, I hope this helps,
Bob

 

[Luto]

Luno,

Thank you for your thorough demonstration of the issue. That was pretty great, and I appreciate it. $:^ ]

1. The global.font variable is acting exactly as expected, exactly as designed, and exactly as I described up above: Every time you use one of the font_add*() functions (much like functions to dynamically add other assets), your new font gets an index added to by 1 (compared to the previous asset of the same type) in order to avoid conflicts with previously created resources -- whether or not the previous ones have been deleted. (This way, you can still test the old one for deletion while testing the new one for existence. If it stayed the same, your old destroyed ones would test positive for existing -- whoops, not good.) Then, every time your particular coding uses said function, it's assigning that newly created index to the same variable. This way, global.font keeps getting a new value assigned to it every time you create a font. (That's no leak. The numbers 0, 4294967296, and -3.1415926535897932384626433832795 all take the same amount of space assigned in GM's real variables -- technically, "floating point doubles.")
2. Since you're still going between rooms, and @jackhigh24 sends the alert that all room-changing functions are acknowledged as tiny memory leaks, your test is still not controlled. Try creating and destroying fonts in conjunction with nothing but keypresses -- not even instance creation/destruction; too, try going between rooms without modifying anything else. See what those tests garner for you.

Again, I hope this helps,
Bob

ok, i did the tests.

1- In the first test i used only the keypress released event with font_add_sprite_ext() to assign it to global.font and then delete it. the results are the same that previous tests. (sorry for the music, is to keep my morale up. XD) NOTE: the global.s is only to keep the correct behavior when i press key A.

////CONTROL OBJECT
//create event
global.font=0;
global.s=0; //this allows me the correct control of changes in variable global.font

//key released A event
if (global.s==1)
{
if (font_exists(global.font))
{
font_delete(global.font);
global.s=2;
}
}
if (global.s==0)
{
if !(font_exists(global.font))
{
global.font=font_add_sprite_ext(spr_font, "abcde" , true, 2 );
global.s=1;
}
}
if (global.s==2)
{
global.s=0;
}

2- In the second test i only assign font_add_sprite_ext() to global.font and i go between rooms. i not delete nothing and the variable not adds +1 and the memory is totally correct. exactly that you said. =)

////CONTROL OBJECT
//create event
global.font=0;
global.font=font_add_sprite_ext(spr_font, "abcde" , true, 2 );

//key released A event
var r=0;
r=room_get_name(room);

if (r=="room_1")
{
room_goto(room_2);
} else {
room_goto(room_1);
}

now, my question is with the first test. what would happen, if the user want to assign font_add_sprite_ext() to his variable and then delete it without go between rooms?... the previous ID of the font is overlapping to the new font ID. what is the form to correct it? or what am i doing wrong?

 

[Drewster]

You can't expect the index of the font to be 1 every time you create it. It can be anything. The fact that it isn't 1 doesn't mean there's a memory leak.

 

[Luto]

You can't expect the index of the font to be 1 every time you create it. It can be anything. The fact that it isn't 1 doesn't mean there's a memory leak.

ok. the ID to the new font can't be 1 every time that is created. maybe now i understand it.

then if i want use other font i will replace it with the function font_replace(); not eliminate it and then create other because i would be reserving a new ID plus the old one?

 

[Luto]

well, i did another test, this time with the function font_replace_sprite_ext(); and the global.font not assign other ID in every change of room. BUT the memory used goes up every time i change the room.

//create event
global.font=0;
global.font=font_add_sprite_ext(spr_font, "abcde" , true, 2 );

//room start event
draw_texture_flush(); //this was for despair XD
var r=0;
r=room_get_name(room);
if (r=="room_1")
{
font_replace_sprite_ext(global.font,spr_font, "abcde" , true, 2 );
} else {
font_replace_sprite_ext(global.font,spr_font_2, "abcde" , true, 2 );
}

//release A key event
var r=0;
r=room_get_name(room);
if (r=="room_1")
{
room_goto(room_2);
} else {
room_goto(room_1);
}

//draw end event

draw_set_font(global.font);
draw_text(16,16,"abcde");
draw_self();

 

[jackhigh24]

yes like i said changing rooms will keep increasing the memory used, it will never be freed from what iv seen, only time is if you quit and run the game again, its such a small increase that i think it will never be fixed, so you might as well just carry on with your game.

 

[Luto]

yes like i said changing rooms will keep increasing the memory used, it will never be freed from what iv seen, only time is if you quit and run the game again, its such a small increase that i think it will never be fixed, so you might as well just carry on with your game.

ok, then we can consider this like a false-positive? and we can continue developing?

 

[jackhigh24]

might as well as its not going to get fixed any time soon.

 

[Luto]

might as well as its not going to get fixed any time soon.

ok... that's really sad and disappointing =(

 

[jackhigh24]

im only guessing it will never be fixed, you never know one day it might be, but like i said as its so small an increase i cant see them ever fixing it.

 

[ParodyKnaveBob]

Not a false positive!

When you ran my first suggested test, I saw the memory increasing despite using almost nothing but the font_add*() and font_delete() functions. That made me go a-searchin'. So yeah, Mantis bug #15982: Functions: Memory leak in font_delete and font_add. $:^ ]

(However, the room changing and indices incrementing, again, is another issue. Glad you got that sorted.) Yep, font_replace() is quite a valid approach; I've used background_replace() myself for such things.

Regards,
Bob $:^ J

 

[Luto]

Not a false positive!

When you ran my first suggested test, I saw the memory increasing despite using almost nothing but the font_add*() and font_delete() functions. That made me go a-searchin'. So yeah, Mantis bug #15982: Functions: Memory leak in font_delete and font_add. $:^ ]

(However, the room changing and indices incrementing, again, is another issue. Glad you got that sorted.) Yep, font_replace() is quite a valid approach; I've used background_replace() myself for such things.

Regards,
Bob $:^ J

wow, seems to be an old problem... in this mantis bug tracker web page, i can report the bug again? because i could upload my tests files there.

regards, thanks for the help.

 

[ParodyKnaveBob]

1. I'm pretty sure you can't just go sign up for an account anymore for YYG's bug tracker,
2. not every account is able to report new bugs, and
3. anyone with an account shouldn't report a duplicate bug anyway: one should instead add to the bug already reported.

On that note, you might write the YYG Help Desk and mention bug #15982, and even attach your GMZ (although that report already has a demo project).

You're certainly welcome. $:^ ]
Bob

 

[Drewster]

wow, seems to be an old problem... in this mantis bug tracker web page, i can report the bug again? because i could upload my tests files there.

regards, thanks for the help.

Just looked at the mantis link you posted -- it shows as resolved -- as of Saturday Oct 8 2016.

 

[rwkay]

I fixed it on Saturday, after reading the post here, took a while to track down though as the behaviour differs depending on what type of font it is. This is the main reason we need an attached example project as if the report was just font_delete() leaks memory I would have dismissed it as a normal font does not leak, it was only the TTF font that leaked.

Russell

 

[Drewster]

I fixed it on Saturday, after reading the post here, took a while to track down though as the behaviour differs depending on what type of font it is. This is the main reason we need an attached example project as if the report was just font_delete() leaks memory I would have dismissed it as a normal font does not leak, it was only the TTF font that leaked.

Russell

Thanks Russell!