View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0005887 | Valley 1 | Crash/Exception | Feb 14, 2012 4:10 am | Mar 30, 2012 1:04 pm | |
| Reporter | c4sc4 | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | open | ||
| Product Version | 0.576 | ||||
| Summary | 0005887: Crash after Dragon Fight | ||||
| Description | I was fighting a crippled dragon in a boss tower and it was a bit strange, I think some of the images didn't load. It's fire was boxy and while the dragon moved it flashed. See attached screenshot. Anyway that's the minor part. A few seconds after I defeated the dragon, the game crashed. I got a popup, I think a unity one, saying something like 'the game crashed,these files were created, it would be nice of you to tell the devs.' So here is a zipped file of all of the crash files it created. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | New | ||||
| related to | 0006952 | closed | Fatal error in Sp world after entering an Ice age building stash. Not sure if memory leak. |
|
|
Wow! Can those half-loaded things be a monster in the Deep or a spell or something? They look cool. |
|
|
Josh, can you pull up a game with a crippled dragon and see if you can duplicate the errors? If so, please post a world file. |
|
|
I just found a fight w/ a dragon, and all was fine. |
|
|
Okay -- then in that case, I think we have a bad install here, c4sc4. Most likely a good idea to install via 0.540 installer and then update to the latest. I think that some updates were missed, or something like that. |
|
|
Huh, alright so I decided to try the fight again before reinstalling to see if the problem would happen again, it didn't. The dragon and fire looked normal and it didn't crash afterwards. Might be a good idea to reinstall anyway. |
|
|
One note: it looked like your RAM was very low from the logs you posted. You don't have any swap space set up, and only seem to have 2GB of user space RAM, which isn't the best combination. Hitting that RAM threshold can make strange things happen, rather than the OS just picking up some swap space and moving background processes over there. It is very likely that was the source of this problem, since you're not seeing it on a second run. |
|
|
Speaking of RAM... Unity is the sole cause why you can't use more than 2GB, right? Or was the limit even 800MB? |
|
|
"Speaking of RAM... Unity is the sole cause why you can't use more than 2GB, right? Or was the limit even 800MB?" All our games can use up to about 3.2GB of RAM for data in general -- textures and the like. The 800MB limit is on Mono heap space, which refers to data structures only. That's something we bump up against in massive AIW games, but we rarely pass even 200MB even in the largest AVWW worlds. We learned our lesson and made more of the world state persist to disk with this one. ;) |
|
|
I do have 8 GBs of RAM installed in my computer though so I'm not sure why it be so low. The only things I had running was Firefox, Steam and AVWW, so unless one of those had a memory leak, I don't think it should be that low. I don't quite remember turning off the swap but the may of happened when I upgraded my RAM. |
|
|
Hmmm, that is really odd. This is what I see from your error log: 58% memory in use. 0 MB physical memory [3356 MB free]. 0 MB paging file [0 MB free]. 2048 MB user address space [89 MB free]. Though in another log from that same crash dump, I do see this: systemMemorySize:8093 I'm not sure what the deal is with the crash log reporting such low numbers, that's really odd. |
|
|
And actually it looks like the paging file is turned on still, it's automatically managed by windows so I don't know why it wasn't being used when it crashed. |
|
|
So it happened again. I reinstalled the game and I found another dragon in a rare commodity tower. The game reported some errors(see new attached file) and the dragon and fire looked strange again. Once I defeated the dragon, the game crashed and created another bunch of crash files. Both times I had been playing the game for at least 30 minutes prior to the crash. |
|
|
Okay, thanks -- that confirms what I had suspected. You're running out of RAM. I know that sounds crazy, but that's what is happening. It's trying to allocate a texture, and the game is then crashing because it doesn't have enough. Given that you have 8GB of RAM that's obviously strange, but the game is reporting that your user space RAM is only 2GB, and with the OS in that I'm not surprised you'd be running out of space (it's also reporting no swap space). I'm not really sure what that means, why the user space RAM is so low, but does that ring any bells for you? Usually user space RAM is identical to the system RAM, but on your computer it appears they are not. At least in how Unity is able to query them, let's put it that way -- but given others are not reporting this, I'm inclined to think it's something on your OS install rather than a unity thing, in the main. Are you running a VM or something? |
|
|
I'm not running a VM or anything else that would steal RAM, at least nothing I can think of. I'm going to try and see if I can get the game to crash again tonight and see what windows reports my RAM usage at to see if I am truely running out of RAM or if unity just can't see all of my RAM for whatever reason. |
|
|
Okay, makes sense. |
|
|
Ok so I collected some data and will upload the txt file with it, don't know if it will be helpful. Also, the massive jump in RAM usage by AVWW is because I visited every unique region type I could to load as much data into RAM as possible to try and get it to crash. It looks like when it crashes I do run out of RAM, well free RAM at least. At the time of the crash I still had 3.7 GBs of RAM available but it is standby RAM, which should be usable by anything that needs it. EDIT: Also, when it crashed, the resource manager mentioned that the AVWW process had a hard fault. |
|
|
Okay -- all that makes sense, and AVWW is looking around like what it should in terms of usage there. Nothing jumps out at me as being overly high for what you did, in other words. What strikes me as strange is that the free RAM is so low. I'm not sure what standby RAM is, I've never heard of that before. What's curious is that when I look at task manager, I'm running mine even lower, though. I've got 8GB of physical RAM also, and my free RAM is getting as low as 25MB with no problems. Meanwhile, my memory in use by other stuff is 5.5GB before AVWW is even started. Do you have a save you could upload, with steps to repro? Maybe this has something to do with your world being so incredibly large, now that I think about it; your world is the largest on record, so far as I know. |
|
|
Well according to the recourse manager, standby memory is 'Memory that contains cached data and code that is not actively in use' and available memory includes Standby and Free memory. I can upload my save, I'll post a link in a few minutes. As for the steps to reproduce it here's what I did. 1) Visit as many regions as possible to get the game to load as many resources as possible. 2) Find a region that can spawn a dragon boss and that has either a boss tower mission or a evil outpost on it. Enter the boss room and it the boss should be bugged. Hopefully that should reproduce it for you. When I just got it to happen, I did visit a few buildings and stash rooms before finding the boss. |
|
|
Here's a link to my world. http://dl.dropbox.com/u/11693401/DragonCrash.rar |
|
|
Wow, that is one large world. I wasn't able to duplicate the crash, but then again I didn't really try to. I was able to duplicate the too-fast RAM growth, and that was enough to cause me to hunt some things down. I've now got it so that it sticks within the 500-800MB range when it would be in the 700-1700MB range instead based on my own tests. I'm sure it will still get higher than 800MB, but it should do so vastly slower and I don't expect that you'll be able to trigger this particular issue again anytime soon -- knock on wood. As an aside, looking at your world's RAM footprint in terms of heap space (the thing that is limited to 800MB in Unity's version of Mono), I see that you're rarely getting above 100-150MB now. It was creeping up to 200MB, but I think that was the white outline textures (see below). Anyhow, either way I don't think that was related to the problem, as it should have been 1/4 capacity on the heap at worst. But it was dying when it was trying to allocate a white outline texture, so clearly it was having some trouble with that part of RAM. I'm not sure if that was partly GPU RAM or what, but that wouldn't really make too much sense. It's a bit of a black box, so my knowledge of exactly what is happening with those texture allocations is unfortunately a bit fuzzy. Anyway, this is what has changed so far, and will be out tomorrow sometime: * Months ago, well before beta, we had built in capabilities for dumping textures from RAM. However, there was never really a clear case where we needed to do that, as our total volume of textures was low enough not to cause too many issues (under two gigs). And we kind of figured that once it started becoming a problem, we'd start hearing about it and could do something about it then; but without a clear use case, we'd be shooting in the dark. So we built the unload mechanism without actually making the game trigger that mechanism, to await a time when it might be needed. ** That time is now. Surprisingly the machine in question that was having some issues with RAM is an 8GB beast, but so it goes. It's also the largest-known world (50MB on disk), belonging to alpha tester c4sc4. It's actually not possible to get worlds that large very easily anymore, and the worry we thought we'd have -- heap space -- actually turned out not to be an issue. But with a slightly larger-than-average heap space, and then lots of RAM being used by textures, it was getting to where he could trigger a crash. ** Thus, the game now unloads most of its side-view textures, except for things like particle effects and those images associated with your own character, any time you visit the world map. This keeps there from being unbounded texture RAM growth if you explore lots of regions in one play session. As we continue to add more and more images to the game, this problem was only going to compound anyhow (and it has since alpha), so this problem neatly bounds the problem and should solve the issue completely. ** The downside of this unloading is that, of course, the game later has to reload those same images off disk again later on. Since we only do this when going to the world map, however, that is rare enough to not really be annoying. And on a 7000 RPM hard drive, the reloading of the related textures tends to take 1-3 seconds, so we're not talking about a lot of time here. ** Thanks to c4sc4 for reporting this issue. * As part of our quest to reduce RAM use -- and load times -- we've made it so that the glowing colored outlines that get used whenever you cast a spell now only applies to player characters and NPCs. In other words, not to enemies (and, actually it was mistakenly applying these to static objects -- trees, rocks, etc -- which was slowing things down even more previously). ** Each type of entity that uses this effect causes extra load time (to create an in-memory texture that contains their outline) as well as extra RAM (to hang onto that texture that was generated. So severely cutting back which enemies use this really is a huge savings, particularly when you figure in minibosses and larger -- their textures are massive enough as it is, that it becomes enormously wasteful in the end. Thanks! |
|
|
For the sake of trying to keep Mantis clean, I'm going to resolve this one now then. If something happens again c4sc4, please don't hesitate to let us know. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Feb 14, 2012 4:10 am | c4sc4 | New Issue | |
| Feb 14, 2012 4:10 am | c4sc4 | File Added: Screenshot_2012_02_14_01_03_12.png | |
| Feb 14, 2012 4:11 am | c4sc4 | File Added: Crash_2012-02-14_002448.rar | |
| Feb 14, 2012 4:21 am | martyn_van_buren | Note Added: 0019072 | |
| Feb 14, 2012 8:56 am | Chris_McElligottPark | Note Added: 0019079 | |
| Feb 14, 2012 8:56 am | Chris_McElligottPark | Assigned To | => tigersfan |
| Feb 14, 2012 8:56 am | Chris_McElligottPark | Status | new => assigned |
| Feb 14, 2012 12:20 pm | tigersfan | Note Added: 0019114 | |
| Feb 14, 2012 12:21 pm | Chris_McElligottPark | Note Added: 0019115 | |
| Feb 14, 2012 12:21 pm | Chris_McElligottPark | Status | assigned => feedback |
| Feb 14, 2012 12:51 pm | c4sc4 | Note Added: 0019116 | |
| Feb 14, 2012 12:51 pm | c4sc4 | Status | feedback => assigned |
| Feb 14, 2012 12:57 pm | Chris_McElligottPark | Note Added: 0019118 | |
| Feb 14, 2012 12:59 pm | Toll | Note Added: 0019119 | |
| Feb 14, 2012 1:03 pm | Chris_McElligottPark | Note Added: 0019120 | |
| Feb 14, 2012 1:07 pm | c4sc4 | Note Added: 0019121 | |
| Feb 14, 2012 1:12 pm | Chris_McElligottPark | Note Added: 0019122 | |
| Feb 14, 2012 1:12 pm | c4sc4 | Note Added: 0019123 | |
| Feb 14, 2012 10:07 pm | c4sc4 | Note Added: 0019154 | |
| Feb 14, 2012 10:07 pm | c4sc4 | File Added: ErrorsReportedByEngine.txt | |
| Feb 15, 2012 8:55 am | Chris_McElligottPark | Note Added: 0019161 | |
| Feb 15, 2012 2:05 pm | c4sc4 | Note Added: 0019173 | |
| Feb 15, 2012 2:08 pm | Chris_McElligottPark | Note Added: 0019174 | |
| Feb 15, 2012 10:06 pm | c4sc4 | Note Added: 0019184 | |
| Feb 15, 2012 10:06 pm | c4sc4 | File Added: AVWW_mem_usage.txt | |
| Feb 15, 2012 10:08 pm | c4sc4 | Note Edited: 0019184 | |
| Feb 15, 2012 10:17 pm | Chris_McElligottPark | Note Added: 0019185 | |
| Feb 15, 2012 10:26 pm | c4sc4 | Note Added: 0019186 | |
| Feb 15, 2012 10:27 pm | c4sc4 | Note Added: 0019187 | |
| Feb 15, 2012 11:45 pm | Chris_McElligottPark | Note Added: 0019189 | |
| Feb 15, 2012 11:45 pm | Chris_McElligottPark | Assigned To | tigersfan => Chris_McElligottPark |
| Feb 15, 2012 11:45 pm | Chris_McElligottPark | Status | assigned => feedback |
| Feb 16, 2012 7:22 am | tigersfan | Internal Weight | => New |
| Feb 16, 2012 7:22 am | tigersfan | Note Added: 0019210 | |
| Feb 16, 2012 7:22 am | tigersfan | Status | feedback => resolved |
| Mar 30, 2012 1:04 pm | Chris_McElligottPark | Relationship added | related to 0006952 |
| Apr 14, 2014 9:28 am | Chris_McElligottPark | Category | Bug - Crash or Exception => Crash/Exception |
