Memory Leak --> Crash

#1

Hey I love this game, excellent job – going to rebuy it on Steam once it comes out just to support you.

I have a reproducible crash that (I think) works on all levels, at least the numerous stages I’ve played on NG+ recently.

Save file uploaded, go ahead and test on Following Zelemir (the next level in this save that isn’t 3 gold stars)

  1. Start stage
  2. Immediately pause and place units
  3. Unpause… play for some time (1-5 minutes)
  4. Go to options --> restart level
  5. Repeat (pause, place units, play 1-2 minutes, restart level)

After 3-4 cycles the game freezes, exits fullscreen mode (goes to window mode) – still frozen, and then will not unlock. Defender’s Quest must be force-closed through the Windows OS at this time.

I’m playing on Win 7 SP1 with latest updates/fixes, Crossfire Radeon 4870, AMD Phenom II X4 965, 4GB ram.

The game is set to fullscreen, 1900x1200. I’m not playing with “scaled” enabled for the resolution.

Please let me know if you need more information… just trying to help the game get ready for wider release!

Great work, love the game!

#2

Crucial bit of info that’s missing - the game version :slight_smile: .

This sounds very much like a bug that was fixed in 0.9.58.

Also, how many units you’re placing? And will it crash even if you do it without playing, that is summon/boost/recall defenders X times?

#3

I believe this bug has already been fixed, though for good measure I tried the above steps and was unable to reproduce the symptoms.

There is a possible edge case I originally overlooked, however - since you were constantly restarting the battle without exiting to the overworld, the engine technically will never clear the graphics cache entirely, which could cause some problems. Even if battles have been fixed so that the worst memory leak is over, restarting battles over and over (in theory) could build up a big stack of memory that isn’t freed until you hit the overworld. (The overworld constructor has a call to clearGraphicsCache() )

I stuck a clearGraphicsCache() call at the end of the State_Play() destructor (the class that corresponds to the battle engine itself), so whenever you restart a battle now, it will clear the graphics cache. If I clear the graphics cache at the wrong moment, this can cause weird bugs, so although I think I did it right this could potentially cause strange behavior or crashes if something is still being drawn to the screen when its underlying graphic data is cleared out.

So, hopefully this should fix it. Changes will be in 1.0.2

#4

Thanks! Hoping that version 1.0.2 fixes the problem.

This was from the latest version, 1.0.1

Maybe it’s some artifact of my system… I’m still able to re-create this bug continuously. I think it might be from something new, I didn’t have any problems before the latest couple of updates.

#5

I’m getting reports from others about a memory leak and crashing in 1.0.2, but it might have a different cause. The super-duper sheep level is apparently causing problems, and the current theory is the “delayed damage queue” might be the chief culprit.

#6

that might explain why it hasn’t happenned to me so far - I’ve recently spent several hours playing with one-char party, so I never created big damage queues on any creep, which 6 weakish archers could easily manage…

#7

Closing this for now, assuming this was fixed with the damage queue. If it happens again I’m sure someone will post about it :slight_smile:

#8

I’m not 100% sure I would call this fixed.

GcFli.jpg752×551 79.5 KB

This was on the Endless Challenge 2, although I had played a few other maps before that. Crashed at level 57.

Edit: I can’t even complete Endless Challenge 2 at all. I tapped out at level 98, pressed ‘Cash Out’ and the game wouldn’t end the level. Again, memory usage had gone from ~270MB at launch to 1.4GB in the space of that one map…
This is on version 1.0.22.

#9

Okey dokey then!

#10

I run windows 7 and i use version 1.0.22.
both times this has happened with the sheep at the gap and the screen shuts me out of fullscreen mode and locks up. I even let it sit to see if it just bogged down, but hours later it was still unresponsive.
[attachment=0]DQ error.png[/attachment]

#11

Thanks for this info. I’ll make this one of the bugs I try to get in the next patch. We might not be able to release the next patch on Monday because I’ve been touching to many things in the code to have it be stable and ready, so we’ll shoot for later next week. Hopefully I can nail this one and get things stabilized before then.

#12

I think this is an unrelated memory leak, the 1.0.22 patch fixed the one I referenced as far as I can tell. Thanks for all the hard work (and good luck with the new issue posted here!).

#13

Fix for this bug is in version 1.0.27, and is hitting the test server today.