Multiple issues found with savegame

0 favourites
  • 5 posts
From the Asset Store
Use this game pack to create your own game, modify the existing game or simply take a look and see how it was made.
  • This is a continued from

    I found something:

    Problem Description

    The issues are as follow:

    1. Memory Leak: save game causes memory leak in Chrome and Node Webkit.

    2. Firefox: using dictionary and save game OR sometimes just save game alone cause javascript error.

    Attach a Capx

    http://www.mediafire.com/download/mdp5q5h56zznj15/testSaveLeak.capx

    Description of Capx

    The capx has 2 layouts and each of them has an event sheet that includes the main event sheet. Hold space to rapidly change between these two layouts. The reason is to demonstrate that save game on start of layout leaves memory leak.

    Steps to Reproduce Bug

    • Step 1: you need Performance Monitor tool or any tool that could measure memory consumption over time.
    • Step 2: run the capx on preview Chrome and/or exported Node Webkit.
    • Step 3: hold space bar to rapidly changing between layout 1 and 2 for about 10 seconds. You should see a spike in memory consumption.
    • Step 4: now wait. Wait for a while, and you should see the memory consumption coming half way down. Wait longer and you will see that memory didn't go down further. Give it roughly 15 minutes to see whether garbage collector can do its job. See Figure 1 below.
    • Step EXTRA: you can repeat step 3 and 4 and you will see memory consumption goes up and only come half way down again. See Figure 2,3,4.
    • Step 5: Try disable save game statement in capx and run capx again.
    • Step 6: do step 3 this time, and you will see memory does come down to almost initial value. See Figure 6.

    Both Chrome and Node Webkit yield identical result. See Figure 5.

    For Firefox, the issue is different. If you run the capx, you got a javascript error. See Figure 7. However, sometimes, I disabled dictionary add keys action and it runs fine. But sometimes it does not. In our game, we also run into this issue on Firefox, but if we do not save game, this does not occur.

    Observed Result

    There seems to be a memory leak in Save game function.

    ----------

    Figure 1: by holding space for 10 seconds, memory consumption goes up, but eventually it dropped down to only half way for the rest of the time.

    ----------

    Depending on Garbage Collector, sometimes memory would not come down immediately as well, but eventually it will come down, but only half way. Figure 2, 3, 4 below are from the same run:

    Figure 2: holding space bar and memory stays up.

    ----------

    Figure 3: after a while, memory consumption drops to half way.

    ----------

    Figure 4: holding space bar again, and you see the curve goes up again and then come down to half

    Note that Figure 1-4 are all Node Webkits.

    ----------

    Figure 5: I see that both Chrome (purple line) and Node Webkit (blue line) have pretty much identical result. They go up but never come down more than half way. For Chrome, I hold space twice so that's why it goes up twice.

    Another interesting thing to note is that Chrome has the gradually increasing memory consumption at constant after holding down space. From my previous post in another thread, I have also observed this behavior also holds true in Node Webkit. But whether this occurs or not could be random. In my game, memory keeps on going up like in Chrome in this case, when it is running in Node Webkit.

    Figure 6: this shows what happened when save game has been toggled disabled. I hold space bar down twice, so you see two spikes here. The memory spiked up but eventually both of them get back down to initial memory value. This is in Node Webkit, by the way.

    Figure 7: running capx on firefox yields the javascript error above.

    Expected Result

    There should not be memory leak when using save game.

    Firefox should also not have javascript error.

    Affected Browsers

    • Chrome Version 36.0.1985.143 m: YES
    • FireFox 31.0: YES
    • Node Webkit (exported from r173) : YES

    Operating System and Service Pack

    Win7 64 bits Service Pack 1

    Construct 2 Version ID

    r173

    This is a smaller scale bug reproduction. The save file for this capx is rather small ~40 KB, but in our game, our save file goes up to 700 KB, and as we play on and on, our memory hits 800 MB in less than an hour, and it just never gets back down at all. Sure, there are other factors such as more events, objects, etc. But also recall from figure 5 above, our app in Node Webkit has that gradually increasing memory behavior after playing the game for a while, and at that time, we already leave it untouched - no new objects created, etc., yet memory still goes up. (this is also discussed in )

    Could you please investigate what went wrong in the save game function?

    For us though, we are making a game on Node Webkit, so we would be grateful if you could focus on chromium side first. In fact, we do not really care about the Firefox issue. It's the Node Webkit / Chrome issue that is our major concern right now.

  • Did you try r176? I'm not sure that this issues were fixed there, but some firefox bugs were fixed in r176, and node-webkit were also updated.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • The same caveats about working sets that I mentioned in the other post apply here. I have reviewed most of our saving code and made some measurements with Chrome dev tools. I am pretty sure there is not a memory leak in our code. This does not rule out a memory leak in Chrome itself, but I think it is more likely to be making use of system memory for caches if it knows there's lots of system memory available. (After all if you have gigabytes of memory going empty, why not use it?) The save code does generate a pretty large JSON object, stringify it, then discard it immediately, so it may show up clearly when the collector decides to do a full GC sweep (until that happens there are likely lots of large JSON objects and their string counterparts hanging around unused in memory from previous saves).

    I can't reproduce that error on Firefox, btw. Were there any special steps to follow to get it to appear?

    I've tried disabling the IndexedDB backend for saving, making it save to WebStorage instead. It seemed to avoid using so much memory. So perhaps it is related to that. IndexedDB saving is asynchronous, and this particular example is unique in that unlike most realistic games it creates multiple save requests in parallel, since it does not wait for "On save complete" to trigger before changing layout then issuing a new save request. That may be related to the error in Firefox, and it may be related to your original game, which may accidentally make large numbers of save requests such as by trying to save in an event that is true every tick. Still, unless the game at some point actually runs out of memory and crashes or shows a JS error, I can't say this is definitely a bug in our code.

  • Ashley, I just hit preview from Construct 2 to preview on Firefox and I got that error. There were no other steps.

  • And my game only saves on the start of the layout though. When I disabled that save game action, it does not show such error on Firefox.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)