http_request causes memory leak ( probably my fault )

Discussion in 'Programming' started by RaverockMediaLtd, Jun 13, 2019 at 4:41 AM.

  1. RaverockMediaLtd

    RaverockMediaLtd Member

    Joined:
    May 5, 2019
    Posts:
    8
    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
     
  2. Catan

    Catan Member

    Joined:
    Jun 20, 2016
    Posts:
    549
    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: Jun 13, 2019 at 9:36 AM
  3. zbox

    zbox Member GMC Elder

    Joined:
    Jun 21, 2016
    Posts:
    785
    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 :)
     
  4. RaverockMediaLtd

    RaverockMediaLtd Member

    Joined:
    May 5, 2019
    Posts:
    8
    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.
     
  5. RaverockMediaLtd

    RaverockMediaLtd Member

    Joined:
    May 5, 2019
    Posts:
    8
    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
     
  6. zbox

    zbox Member GMC Elder

    Joined:
    Jun 21, 2016
    Posts:
    785
    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.
     
  7. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,033
    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.
     
  8. RaverockMediaLtd

    RaverockMediaLtd Member

    Joined:
    May 5, 2019
    Posts:
    8
    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.
     
  9. RaverockMediaLtd

    RaverockMediaLtd Member

    Joined:
    May 5, 2019
    Posts:
    8
    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
     
  10. zbox

    zbox Member GMC Elder

    Joined:
    Jun 21, 2016
    Posts:
    785
    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!
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice