View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010016 | Dwarf Fortress | World Generation -- General | public | 2016-09-25 03:30 | 2016-10-09 19:33 |
| Reporter | Esavier | Assigned To | Toady One | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | Windows 10 | OS Version | 14393.187 |
| Product Version | 0.43.05 | ||||
| Fixed in Version | 0.43.05 | ||||
| Summary | 0010016: Out of memory crash | ||||
| Description | On modded Dwarf fortress (Masterwork 1.16), but propably also on stock. During world generation, with large nubmber of civs, megabeasts, beasts, and titans, DF advanced worldgen will crash in the same place. After patching binary with LargeAddressAware, problem is resolved. | ||||
| Steps To Reproduce | 1.Advanced World Generation, set: Large or Medium Region max-subregions:5000 Titans:1000 Megabeats:1000 Semi-Megabeasts:1000 Civilizations:55 2. generate crash is expected between histroy generation and placing civilizations | ||||
| Additional Information | Large Address Aware link: https://www.techpowerup.com/forums/threads/large-address-aware.112556/ No error logs anywhere. Additionally patched: dfhack and binpatch | ||||
| Tags | No tags attached. | ||||
|
|
MDF 1.16 uses DF 0.43.03, not 0.43.05: http://www.bay12forums.com/smf/index.php?topic=160759.0 There's really nothing that can be done here, short of generating a smaller world. Upgrading to 0.43.05 should fix the issue, so I would bring that up to Meph if nobody has yet. |
|
|
I am not playing on stock MDF, i fixed it up to work with newest DF, however lot features are disabled. I double checked, that this issue is not corelated to modifications made to MDF. Issue persist on stock DF. I tested it through latest two straight days and i narrowed the issue to memory limit problem, without patch its almost always near 2GB, with patch it will crash near 3.8 GB, 4GB including stale memory (paging). I also confirmed with microsoft documentation that x86 application (32bit) are by design limited to roughly 4GB. I belive that this is time to DF to catch up to modern machines, less than 5% devices capable of running DF are not able to use 64bit architectures, and almost always there is present more than 4GB of physical ram - standard was 8GB about 4 years ago for energy saving laptops. Limiting memory will also hamper community's ability to mod and adjust DF, and as such, user experience. Leaving this issue open will either way pop up in future, together with multithreading, because in some point, complexity of computations will take too much toll on users, limiting FPS to unplayable values. Relatively easy fix is to start making and/or change current build to 64bit architecture. This should also help with performance issues. |
|
|
Dwarf Fortress switched to a 64-bit build in version 0.43.05, as mentioned in the development log: http://www.bay12games.com/dwarves/ Does vanilla 0.43.05 crash in the manner you stated? |
|
|
yes indeed. I am sure that i set up properly 43.05 on top of some of Masterwork Raws that do not use special features provided by dfhack. Game is working properly on v.small-small maps for more than 10 in game years. This may be corelated with fact that i am using Insider Preview version of Windows 10, but i seriously doubt it. I will try to set up clean stable windows and test it again but it will take some time (till this sunday for sure) |
|
|
Are you using the 32-bit or 64-bit build of 0.43.05? (Also, I'd like to point out that 64-bit support wasn't simple, and it should not have a very large impact on speed.) |
|
|
ok, on freshly installed windows 10 stable i couldn't reproduce this bug. Propably something related to windows insider preview release, or just virtualbox lies to me for some reason. i used x64 build from DFFD. From my experience migration to wider architecture is not particulary hard. Also from my experience and valgrind stats, difference on this same code between x64 an x86 is on avg. 4-20% faster (depends on code). Notice that i wrote "relatively", and "should" - those indicate that it is statement taken upon my knowledge as programmer who, however, is be not familiar with code but familiar with language. Still i am glad that it is building on x64 already. good work:) Please close it for now. If i came up with something i will reopen. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-25 03:30 | Esavier | New Issue | |
| 2016-09-25 10:56 | lethosor | Note Added: 0035897 | |
| 2016-09-25 10:56 | lethosor | Assigned To | => lethosor |
| 2016-09-25 10:56 | lethosor | Status | new => resolved |
| 2016-09-25 10:56 | lethosor | Resolution | open => not fixable |
| 2016-09-25 10:56 | lethosor | Product Version | 0.43.05 => 0.43.03 |
| 2016-09-25 10:56 | lethosor | Fixed in Version | => 0.43.05 |
| 2016-09-27 04:48 | Esavier | Note Added: 0035912 | |
| 2016-09-27 04:48 | Esavier | Status | resolved => feedback |
| 2016-09-27 04:48 | Esavier | Resolution | not fixable => reopened |
| 2016-09-27 04:48 | Esavier | Note Edited: 0035912 | |
| 2016-09-27 07:43 | Loci | Note Added: 0035915 | |
| 2016-09-27 12:54 | Esavier | Note Added: 0035918 | |
| 2016-09-27 12:54 | Esavier | Status | feedback => assigned |
| 2016-09-30 16:27 | lethosor | Note Added: 0035921 | |
| 2016-09-30 16:27 | lethosor | Status | assigned => feedback |
| 2016-09-30 16:27 | lethosor | Product Version | 0.43.03 => 0.43.05 |
| 2016-10-06 09:35 | Esavier | Note Added: 0035950 | |
| 2016-10-06 09:35 | Esavier | Status | feedback => assigned |
| 2016-10-09 19:33 | lethosor | Status | assigned => resolved |
| 2016-10-09 19:33 | lethosor | Resolution | reopened => fixed |
| 2016-10-09 19:33 | lethosor | Assigned To | lethosor => Toady One |
