http_request causes memory leak ( probably my fault )

R

RaverockMediaLtd

Guest
I'm using http_request for account logins from GMS2 and http_get to poll my SQL database for character locations, equipped items, etc. The database gets http_get'ed every alarm[0] = 30 ( twice a second ). I've adjusted this to once per second but noticed that my RAM gets utterly pummeled this way. The debugger shows that my http_request string which gets saved to the variable "request" is the problem. The "request" variable just keeps growing and growing and growing each time a new request is made. I've made sure to destroy any ds_maps as they are no longer needed so that isn't an issue but the request variable itself doesn't seem to reset to 0 by itself. I even tried to force it to reset to 0 once the request and processing is done but it ignores this. I.E whatever the last request number was ( 244 for example ) if I do request = 0; debugger will flash request = 0 for a second then immediately return to request = 255.

Is there a built in way to destroy the http_request / get's at the end of the ASYNC event once processing their returned data is done?

I'm a PHP / SQL scripter primary so the notion of being able to do API calls from within game maker legitimately made me excited...now I'm wondering if what I want to do is possible ( and If I'm just going about this wrong )

Thanks
 
H

Homunculus

Guest
If by request string you mean the id that gets returned by an http async call, that’s the expected behavior.

Every new request you get a new unique id (that is numeric, not a string) and the number itself is somewhat incremental. This does not cause a memory leak in itself, it’s just an incremental number, and the number 3 for example does not require more or less space to be stored than 183959 in game maker.

If you have a leak, it’s probably somewhere else.
 
Last edited by a moderator:

zbox

Member
GMC Elder
You should show us the code you've got in your ASYNC event too if you truly believe it occurs there - the map created by the event is automatically destroyed but commonly there is code in there to persist parts of the response.

RE: If an account system is actually possible for GM, it definitely is - One of my assets, GMAccount, revolves around this premise :)
 
R

RaverockMediaLtd

Guest
I'll be happy to provide the ASYNC code as soon as I get home this evening. I have noticed that at the very end of ASYNC event I called Alarm[0] = 30 to restart the http_request and if I comment that line out -> //Alarm[0] = 30 my memory leak stops but then my updates stop happening because I'm no longer looping the request.
 
R

RaverockMediaLtd

Guest
Code:
if ( request_character && async_load[? "status"] == 0 )
    {
        var json = async_load[? "result"];
        var map = json_decode(json);
            
        //PLAYERS FOUND
        if ( ds_map_exists(map, "character_name") && map[? "character_name"] != "NONE" )
        {
            //LOAD PLAYER ARRAY
            if ( character_id = map[? "character_id"] )
            {
                character_name = map[? "character_name"];
                character_level = map[? "character_level"];
                character_zone_id = map[? "character_zone_id"];
                character_x = map[? "character_x"];
                character_y = map[? "character_y"];
            }
        }
        
        ds_map_destroy(map);
        
        //REFRESH
        request_character = undefined;
        alarm[0] = 60;
    }
This is my current ASYNC event code. I have only just begun dealing with the GMS2 Async functions so if I have done something incorrectly please let me know. Thank you all for the help
 

zbox

Member
GMC Elder
Yeah OK fair enough no leaks in your code and furthermore if I just create a new project and call http_* every step the memory fills up. This may or may not be a memory leak, it may just also be intentional that it caches past response and purges them once it gets too much. Maybe flick YYG an email and see what they say about it.

I would say don't worry about it because free RAM is useless RAM but yeah... My process is sitting at 2gb used with just web requests which does make me a little uncomfortable.
 

FrostyCat

Redemption Seeker
It's improper to not check async_load[? "id"] to ascertain the source of an asynchronous event, especially in a situation like yours where it fires frequently and risks cross-interacting with other simultaneous requests. Save the return value of http_request() and check async_load[? "id"] against that before acting.
 
R

RaverockMediaLtd

Guest
It's improper to not check async_load[? "id"] to ascertain the source of an asynchronous event, especially in a situation like yours where it fires frequently and risks cross-interacting with other simultaneous requests. Save the return value of http_request() and check async_load[? "id"] against that before acting.
I was but removed that check due to another strange issue where the check itself would fail when by all accounts it shouldn't have. I have since corrected that problem but hadn't returned the check back to my code. But yes I agree.
 
R

RaverockMediaLtd

Guest
Yeah OK fair enough no leaks in your code and furthermore if I just create a new project and call http_* every step the memory fills up. This may or may not be a memory leak, it may just also be intentional that it caches past response and purges them once it gets too much. Maybe flick YYG an email and see what they say about it.

I would say don't worry about it because free RAM is useless RAM but yeah... My process is sitting at 2gb used with just web requests which does make me a little uncomfortable.
I started it up today and changed my alarm[0] = 60 at the end to alarm[0] = 80 and the memory leak is gone. I never get above 80MB of RAM now. Idk what the deal with that is
 

zbox

Member
GMC Elder
Really? That's pretty weird, I wouldn't consider timing to be an issue. Perhaps flick them an email anyway, it might come back to haunt you!
 
Top