narFsnw's Forum Posts

  • Problem Description

    Memory leak (or save file leak?): the "collmemory" section of a savefile gets larger and larger after the game has been closed, relaunched and loaded from a savefile.

    Attach a Capx

    https://dl.dropboxusercontent.com/u/313 ... empty.capx

    Description of Capx

    Spawn objects that are destroyed on collision with another object. The capx also autosave every 1 sec and output the savefile to the browser console.

    Steps to Reproduce Bug

    • Launch the game (Layout "menu").
    • Click on the "New Game" button.
    • Open the browser console: The game saves and output the savefile every 1 sec in the console.
    • Notice that the section "collmemory" (near the bottom) stays empty.
    • Close the game (close the entire tab running the game).
    • Re-launch the game (Layout "menu").
    • Click on the "Load" button
    • Observe the browser console again: the "collmemory" section in the savefile gets bigger and bigger.

    Observed Result

    Memory leak in the savefile: the "collmemory" section keep expending.

    Expected Result

    No memory leak in the savefile: the "collmemory" section doesn't expend.

    Affected Browsers

    • Chrome: (YES)
    • Internet Explorer: (YES)

    Operating System and Service Pack

    Windows 8.1

    Construct 2 Version ID

    r206, 64bits

  • Ah! I finally managed to reproduce the issue in a small capx. I'll write a new bug report in a moment...

  • Ashley Unfortunately, i'm sad to report that the fix does not entirely solve the issue. It did solve the issue in R0J0hound 's small test capx, but in the context of my game, the issue still occur. Some (not all) "collmemory" sections keep expending.

    Problem is, depite my best efforts, I've been unable so far to reduce my project to a small capx that would contain just the issue. Starting from an empty capx, I'm just unable to reproduce the issue. Starting from my game and removing stuff, the issue comes and goes without me being able to understand it.

    Any ideas or advices?

  • Yup! That worked! It cleans every collmemory now. Excellent!

    Here's the final line, as a reference:

    RegexReplace(SaveStateJSON, """collmemory"":\{.*?\}", "g", """collmemory"":{}")[/code:2vsjvf20]

I really need to learn regex for real!

  • Very good idea, R0J0hound !

    One thing though: do you know why it only clean the first collmemory and not the others? I'm not good enough with regular expressions to see why, but right now, it only clean the first collmemory.

  • So, if I understand correctly from what you're saying, the issue will continue to occurs (the savefile will get bigger) unless my players erase their savefile and start a new one?

  • Should be fixed in the next build, thanks for the report.

    Now that Contruct r206 has been released (which includes the fix on this issue), I did some tests and I'm not sure the situation is better.

    Ashley, is your fix supposed to "clean" a savefile that is already full of the ghost data? For example, if I use a savefile that was created on my game in Construct r200, and I load it in my game running in Construct r206, should it remove the corrupted data and reduce the savefile size?

    I'm testing this right now and it doesn't seem to clean it. The savefile remains super big and seems to keep expanding as before.

  • Rocking!! My players will be so happy! Thanks!

  • Nesteris, I suggest that you follow the instructions in this post:

    and submit your bug using the template from that post as a new post instead of as a reply to this one.

  • Based on my investigation, I should add that it's the loading that is the key to reproduce the issue.

    If you just save and never load, the savefile won't get larger.

    As soon as you load once, you can see the savefile getting larger and larger every time you save.

    The part that gets larger in the savefile is a thing called "collmemory" (for collision memory?) It becomes filled with numbers like this:

    "1734838404821996":{"ex":{"collmemory":{"58,2268":[58,2268,28460],"58,2578":[58,2578,32750],"58,3123":[58,3123,40578],"58,4188":[58,4188,57365],"58,4268":[58,4268,58824],"58,4742":[58,4742,66165],"58,5010":[58,5010,70619],"58,6248":[58,6248,90052],"58,6331":[58,6331,91371],"58,6544":[58,6544,94751],"58,7030":[58,7030,102474],"58,9446":[58,9446,140590],"58,9516":[58,9516,141699],"58,9572":[58,9572,142783],"58,12193":[58,12193,183862],"58,12404":[58,12404,187362],"58,12577":[58,12577,189900],"58,13907":[58,13907,210833],"58,15106":[58,15106,229678],"58,15433":[58,15433,234811],"58,15494":[58,15494,235766],"58,16088":[58,16088,245144],"58,16893":[58,16893,257748], .... [/code:17xxl71o]

  • Thanks R0J0hound! Thanks volkiller730! I was really starting to worry here. Thanks!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I was able to isolate the problem in a small capx file.

    [attachment=0:3se9gyue][/attachment:3se9gyue]

    This capx create a lots of orange sprites every ticks, and moves them inside a green box. On collision with the green box, the orange sprites are destroyed.

    That by itself isn't enough to reproduce the issue. You need to first save (using the debugger) and load that savefile (using the debugger). Only by loading the savefile will you start to experiment the issue.

    When you look at the javascript console, you can see the size of the savefile. It quickly gets very big, even if all the objects have been deleted.

    [attachment=1:3se9gyue][/attachment:3se9gyue]

    Steps to reproduce:

    1. Open the capx using Construct's debugger.

    2. Open the browser's javascript console.

    3. Save using the debugger. Notice the savefile's size in the console (about 1 KB).

    4. Activate the sprite creation by checking the checkbox.

    5. Leave it checked for about 5 seconds, then turn it off.

    6. Save again using the debugger. Notice that the issue didn't occurred (savefile is still about 1 KB).

    7. Click "Load" in the debugger to load that savefile. (that's the important step!)

    8. Activate the sprite creation again.

    9. Turn it off after about 5 seconds.

    10. Save using the debugger.

    11. Observe the issue : The savefile is now 100 times larger!

    So... what do I do with this? Is it a bug in Construct?

    What is it saving exactly that makes the savefile so large? Looking at what is inside "collmemory", it's just a few numbers for each sprite, but if they don't get removed when the sprites are deleted, then the savefile gets very huge over time. That's kind of a memory leak, right?

    Should I fill an official bug?

  • After more test, I found out that "collmemory" seems related with the "On collision with..." event. In a new empty project, I start to see "collmemory" in the savefile only when I add "On collision with" events. I assume that "collmemory" would mean "collision memory"?

    I could see how this could lead to my big savefile problem. In my game, lots of sprites are created, then destroyed when they collide with another object. I'm just wondering why data is saved in these cases.

    Any hint?

  • Hello all,

    I have a problem with the savefile of my game but I don't know what it is and where to start my investigation. Maybe one of you will have a suggestion?

    The problem:

    My game's savefile gets too big over time, and reach the browser's file size limit of 5 MB. The thing is: my savefile is normally only 20-50KB which is way under the 5000KB limit. But over time, the savefile gets bigger and bigger.

    I should specify that my game is an idle game (think Cookie Clicker), so it is meant to be left open for days and even month for some of my players. It is also saved and reloaded often hundreds of times. My players with the issue have had the game open for 1-2 months before the savefile reached above 5000KB.

    What I tried so far:

    1) I asked my player to send me his savefile, which I loaded in the game while running Construct's debugger. I can see in the debugger that everything seems normal. I don't see anything that would indicate a memory leak. I was expecting to see an object with billions of duplicates, but no. There isn't a layout with more than 100 objects in it.

    2) I added the behavior "don't save" to most objects that didn't required it (UI elements for example). That didn't help.

    3) I tried to create a new empty project where I create and destroy hundreds of objects every tick, and compared the savefile. I could NOT reproduce my issue this way (the savefile remained clean).

    The savefile

    He's the affected savefile: http://bit.ly/1MlITzU

    Looking at it, I can see which section is taking 99% of the space. It starts like this:

    "1734838404821996":{"ex":{"collmemory":{"58,2268":[58,2268,28460],"58,2578":[58,2578,32750],"58,3123":[58,3123,40578],"58,4188":[58,4188,57365],"58,4268":[58,4268,58824],"58,4742":[58,4742,66165],"58,5010":[58,5010,70619],"58,6248":[58,6248,90052],"58,6331":[58,6331,91371],"58,6544":[58,6544,94751],"58,7030":[58,7030,102474],"58,9446":[58,9446,140590],"58,9516":[58,9516,141699],"58,9572":[58,9572,142783],"58,12193":[58,12193,183862],"58,12404":[58,12404,187362],"58,12577":[58,12577,189900],"58,13907":[58,13907,210833],"58,15106":[58,15106,229678],"58,15433":[58,15433,234811],"58,15494":[58,15494,235766],"58,16088":[58,16088,245144],"58,16893":[58,16893,257748],"58,17632":[58,17632,269421],"58,18070":[58,18070,276300],"58,18653":[58,18653,285566],"58,18667":[58,18667,285801],"58,19836":[58,19836,304567],"58,20152":[58,20152,309332],"58,20310":[58,20310,311876],"58,20956":[58,20956,322135],"58,22376":[58,22376,344412],"58,22637":[58,22637,348509],"58,22703":[58,22703,349869],"58,23228":[58,23228,357859],"58,23685":[58,23685,365071],"58,23855":[58,23855,367876],"58,25208":[58,25208,389170],"58,26185":[58,26185,404569],"58,26278":[58,26278,406022],"58,26463":[58,26463,409113],"58,26761":[58,26761,413675],"58,27026":[58,27026,417827],"58,27711":[58,27711,428661],"58,29000":[58,29000,448719],"58,30517":[58,30517,472695],"58,30543":[58,30543,473110],"58,30879":[58,30879,478351],"58,31540":[58,31540,488785],"58,31647":[58,31647,490430],"58,32104":[58,32104,497702],"58,32379":[58,32379,501990],"58,33637":[58,33637,521774],"58,33748":[58,33748,523725],"58,34339":[58,34339,532881],"58,36110":[58,36110,561142][/code:lczagwcu]

It's followed by about 1500 pages of the same kind of data (yeah, just for fun I tried to print it to see how many pages I would get!) <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> 

As you can see, it starts with "[b]collmemory[/b]" which I tried to search on Google and Construct forums, but could not find anything about it. Do you know what that is? Do you know what is this giant list of numbers?

Any hint would be welcome. Thanks!

  • Oh wow, thanks! I was somehow expecting that it would be considered a normal/expected behavior for Construct, especially since I found a way to prevent this issue with some additional code. But yeah, thanks for the fix. It will make the code so much more clean!