Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009637Dwarf FortressAdventure Mode -- Generalpublic2016-03-18 09:562016-07-28 19:11
ReporterOgg the Blinky Sock 
Assigned Tolethosor 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusresolvedResolutionduplicate 
PlatformApple iMac (27-inch, Late 2012)OSApple OS X YosemiteOS Version10.10.5
Product Version0.42.06 
Target VersionFixed in Version 
Summary0009637: assault on goblin city abruptly plagued by minutes-long processing time per turn
DescriptionI was in the midst of heroically assaulting the Dark Fortress of Curseplan, methodically eliminating all hostile goblins, and was working my way through it underground near the centre of the city. I came to a stairwell that was only modestly unusual in extending four flights or so with antechambers on each level. The game suddenly and abruptly began to take over a minute between movement turns.

I recently quadrupled the RAM on my computer to 32 GB, which had previously sped up movement a great deal. However, the program is currently only requiring 2.55 GB of memory, with at least half the available memory unused, so I don't think that a physical limit is the problem.


Priority is set to "REALTIME" in init.txt, but "ps -l" reports the 'nice' value as zero and the absolute/actual priority as 97. These values however are confirmed to exist since the program launches.

Steps To Reproduce
Additional InformationSave file is at http://dffd.bay12games.com/file.php?id=11867 [^]
TagsNo tags attached.
Relationships
duplicate of 0007526confirmed Dwarfu Dark towers contain thousands of goblins and trolls, causing lag 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-03-18 09:56Ogg the Blinky SockNew Issue
2016-03-21 15:02Ogg the Blinky SockNote Added: 0034893
2016-03-21 15:03Ogg the Blinky SockNote Edited: 0034893bug_revision_view_page.php?bugnote_id=0034893#r14082
2016-03-21 15:03Ogg the Blinky SockNote Edited: 0034893bug_revision_view_page.php?bugnote_id=0034893#r14083
2016-03-21 21:22Ogg the Blinky SockNote Added: 0034894
2016-04-01 01:43jjl2357Note Added: 0034950
2016-04-26 15:02untrustedlifeNote Added: 0035049
2016-07-27 16:17InfantIguanaNote Added: 0035709
2016-07-28 16:42Ogg the Blinky SockNote Added: 0035719
2016-07-28 19:11lethosorNote Added: 0035721
2016-07-28 19:11lethosorRelationship addedduplicate of 0007526
2016-07-28 19:11lethosorStatusnew => resolved
2016-07-28 19:11lethosorResolutionopen => duplicate
2016-07-28 19:11lethosorAssigned To => lethosor

Notes
(0034893)
Ogg the Blinky Sock   
2016-03-21 15:02   
(edited on: 2016-03-21 15:03)
Possibly related to issue 0000136, which seems to be essentially that DF is a 32 bit game and cannot directly address much more than 2 GB of memory.
(0034894)
Ogg the Blinky Sock   
2016-03-21 21:22   
Actually, the above won't affect OS X 32 bit binaries, even less so these days. The program should have access to the full 4 GB addressable space.

Poking around with system diagnostic tools shows that about 19.5 s of a 20 s system call sample was taken up by 'pthread_cond_timedwait' state, which seems to be associated with a call stack of "mach_wait_until > SDL_Delay > SDL_Linked_Version > SDL_SemWait > _pthread_body > _pthread_start > thread_start". There seem to be an inordinate number of sephamores and blocks involved, to my 99% uneducated eye.

Any debugging information that I can figure out how to provide, and which would be useful, I would be happy to provide.
(0034950)
jjl2357   
2016-04-01 01:43   
It might have just loaded an antechamber full of goblins/trolls/etc - goblin fortresses can have _thousands_ of them.
(0035049)
untrustedlife   
2016-04-26 15:02   
I believe this is known already.
(0035709)
InfantIguana   
2016-07-27 16:17   
Just noticed: this is a duplicate of 0007526.
(0035719)
Ogg the Blinky Sock   
2016-07-28 16:42   
I reviewed 0007526 and it seems more likely than not that this is the same issue, although I don't know what the save-file actually holds.

It should probably be closed as a duplicate and noted with a save file link in that report.
(0035721)
lethosor   
2016-07-28 19:11   
Thanks for investigating - I'll merge this into 0007526.

A couple notes:

- The process priority setting only affects anything on Windows
- I'm willing to bet that all the "pthread_cond_timedwait" things you were seeing were just on one thread, probably some SDL event loop-related thread, that was waiting for DF to finish calculating things