View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0002920 | AI War 1 / Classic | Crash/Exception | Feb 23, 2011 5:05 am | Feb 23, 2011 7:59 pm | |
| Reporter | Sukasa | Assigned To | keith.lamothe | ||
| Status | closed | Resolution | not fixable | ||
| Product Version | 5.000 | ||||
| Summary | 0002920: Too Many Heap Sections | ||||
| Description | Happened roughly within five minutes of this save being written. Was playing a decently long game (had recently just passed the 10 hour mark), when the game hung while fullscreened. Alt-tabbed out, and got a message box stating a gc error, that there were too many heap sections. I hadn't done anything in particular at the time, I was just watching the galaxy view while waiting for some fortresses to finish building (I had destroyed two from Dintune and placed one each on Tunejo and Xuzon or whatever it was; the two planets with incoming counterattack waves). If it matters: AIWar + All expansions bought on Steam System specs: 3.06 Ghz i7-950 GTX 570 6GB RAM Win 7 Ultimate 64bit | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
|
|
|
I checked /RuntimeData/, however none of the error files had been modified. |
|
|
Yea, it sounds like the process simply ran out of memory (since it's a 32-bit application like all Unity apps and due to some other strangeness it can only used about 1.7GB before it dies, even with the 6GB on your machine). We've cracked down a lot recently on the game holding onto memory it doesn't strictly need anymore, etc, but it can still happen. There's lots of lists and whatnot that grow to accommodate a large set of ships on a particular planet or a large set of targets for a particular ship, etc, and they don't automatically shrink when the sets go back down (because shrinking them can take up significant cpu and actually increases memory consumption for a brief moment). We've gotten much more aggressive about shrinking those lists, but anyway. Was that a 10-hour session without ever closing the AI War application? If so, that's longer than people used to get before hitting the memory limit :) Closing the app (or having it crash, as in this case) and re-opening it an re-loading the save automatically ditches all that not-strictly-needed memory usage, so you'll be able to play on from there. Though depending on the situation you may not be able to play as long a session as the first time because the "memory floor" is closer to the ceiling. Just took a look at your save, wow ;) Looks like you've got a lot of allied zombies and dyson gatlings buzzing around, those are probably taking up some chunk of RAM (we do need to do something about either capping those or making them more aggressive). But they couldn't be accounting for all that much of it. And the main thing is this: playing on high unit scale. We provide the option for those who want it, and as you saw you can play for rather a long session without problems, but high really pushes the limit of a 32-bit application and sometimes slams right into it. My suggestions: 1) Reload your save, keep playing, it will probably die every 2-3 hours but you can probably finish the game without too much pain from that. 2) In future games, use normal unit scale, or even low if you don't mind it (personally I don't get additional satisfaction from having 196 mkI fighters vs 49 mkI fighters that are each 4x as strong, so I play on low). |
|
|
I definitely prefer normal to low, but agree with the rest. |
|
|
As soon as Unity supports that address extension stuff and/or 64-bit builds, will you take advantage of it? |
|
|
Address extension: yes. 64bit builds: no. That would be desync city, and actually makes the game run slower because of defaulting to all the larger integer types. In the alpha versions of AI War, it was originally able to run in 32bit or 64bit mode, so I can tell you with certainty on both of those. What Unity needs to do is a lot simpler, though, actually -- it's a matter of how much heap space they allow, which is only about 800MB or so. Which means that we aren't even remotely close to the true 32bit process barrier (supposedly Unity already does support the address extension, but we wouldn't know not even having gotten to the 32bit barrier yet because it dies first). And actually, even THAT is not truly what is needed -- in all but the most extreme cases, we don't need remotely 800MB for heap space. I'm talking about 300k+ ships here for needing that much for sure, and even then it's borderline. Rather, the problem is the crappy mono garbage collector, which instead of collecting when it runs out of heap space, throws an error and kills the application. So it's when TRANSIENT heap allocations pass 800MB that there is a problem, even if the baseline heap memory needed is still 300-400MB (which the game almost never exceeds for baseline use). When the GC is fixed to no longer be so suicidal, or to be more efficient with the transient allocations in general, then we'll be golden without needing address extension or any other larger changes. There is an experimental new GC already out that is vastly better from what I hear, but until Mono officially launches that I'm sure it won't be showing up in Unity. So likely another year or so. |
|
|
A garbage collector that crashes instead of collects when the heap is really full is really silly. I can't believe that ever made it into the stable release. (I admit it is tricky to do stuff when you are just out of memory, garbage collection included, but this is a solved problem, and has been solved for quite some time) Is there really no way to tell Unity to tell Mono (or just tell Mono directly) how big you want the heap (on compile-time or run-time or whatever)? |
|
|
Nope. Believe me, if there was anything else we could do, we'd be doing it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Feb 23, 2011 5:05 am | Sukasa | New Issue | |
| Feb 23, 2011 5:05 am | Sukasa | File Added: Autosave.sav | |
| Feb 23, 2011 5:06 am | Sukasa | Note Added: 0010674 | |
| Feb 23, 2011 8:43 am | keith.lamothe | Note Added: 0010676 | |
| Feb 23, 2011 8:43 am | keith.lamothe | Status | new => closed |
| Feb 23, 2011 8:43 am | keith.lamothe | Assigned To | => keith.lamothe |
| Feb 23, 2011 8:43 am | keith.lamothe | Resolution | open => not fixable |
| Feb 23, 2011 8:47 am | Chris_McElligottPark | Note Added: 0010677 | |
| Feb 23, 2011 7:48 pm | TechSY730 | Note Added: 0010700 | |
| Feb 23, 2011 7:54 pm | Chris_McElligottPark | Note Added: 0010701 | |
| Feb 23, 2011 7:57 pm | TechSY730 | Note Added: 0010702 | |
| Feb 23, 2011 7:59 pm | Chris_McElligottPark | Note Added: 0010703 | |
| Apr 14, 2014 9:27 am | Chris_McElligottPark | Category | Bug - Crash or Exception => Crash/Exception |
