Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010595Dwarf FortressMiscellaneous Crashespublic2018-02-27 10:532018-03-03 06:19
ReporterPatrikLundell 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformPCOSWindowsOS Version10.1
Product Version0.44.05 
Target VersionFixed in Version 
Summary0010595: Crash after refusing artifact demand
DescriptionThis save shows at least two bugs:
- 127 quester visitors arriving as the same time (seen in announcements) despite a 40 visitor cap. They trickled onto the map for quite some time, and a couple of normal visitors were announced and arrived well before the last of those (but still listed after them). This may already have been fixed.
- 4 times out of 4 attempts when loading this save DF has terminated abruptly (i.e. the DF window and the DFHack window just disappearing, not with any Windows warning) within a few minutes after starting it. Shortly after loading the save a quester demands an artifact, which I've refused every time. Three times I've locked the western courtyard (F2) doors after the quester leaves while I did nothing the fourth time. The two first times and the last time (no door activity) a quester (not the demanding one) is detected and attacks (nothing will hold me from the Russet Church, or similar). When that happened I've stationed militia squad 1 on the courtyard, and have waited for the enemy to arrive. Twice the enemy has been caught in cage traps (likely because of the locked doors causing them to take a different route than when exiting), while the last time the enemy was still approaching when DF disappeared. The third time a recently arrived quester managed to demand the Russet Church (the same artifact), and DF disappeared immediately upon my refusal.

The reason for the locking of doors was because of my original play (which has been saved separately), where the demanding quester left to the north and I think it was the same one who then went hostile and approached). At that time I stationed squad 1 in the courtyard and engaged and killed the quester. That, however, caused all hell to break out inside the fortress, as fighting broke out. No reports indicated that, however, and all the questing visitors were still marked as green visitors. Most of the questers ran around panicked, while still causing civilian to cancel their activities, a small number were possible to identify as "enraged at all enemies", while a lot of them were fighting without any indications of it (save the missiles one might see). However, animals were killed and mutilated, and citizens attacked (and I found dead bodies in the stairwell). Due to the absence of reports, however, it took me several days to realize there was fighting all over the place and the militia squads training ought to pop over next door to deal with real threats. The locking of doors, to return to that, was intended to delay the attack of a returning quester to delay the return of a sneaking attacker so more questers had time to leave (leaving me fewer infiltrators to fight).
Steps To ReproduceFollow the steps above and wait for either DF to disappear, or for a demand, which caused DF to disappear when rejected (Which I believe Orkel has mentioned happening in the release discussion thread).
Additional InformationLNP r02, Phoebus tile set, raws changed to lower attack triggers of (semi) megabeasts and siege triggers of civs, plus goblins set to start on glaciers exclusively.
DFHacking during world gen to give all regions all plants/animals legal to them, all glaciers made evil, and slabbing of civs to be dead when they out to be. DFHacked pre-embark to allow embarkation as one of the dead civs. Orkel's visitor departure temporary work around.

The save is too large to fit on DFFD, so it can be found here: https://www.dropbox.com/s/sb5brnd52dj2x2e/region6.zip?dl=0 [^]
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0037835)
PatrikLundell (reporter)
2018-02-27 12:02

 3 more attempts: 1 crash, one fight as the attacker is engaged (with the associated mess ensuing), and one case where the sneaker fled, the second demander was refused, and it did NOT crash (yet?).
(0037837)
Orkel (reporter)
2018-02-27 12:34

 DFhack is crashy, crashing my DF every 10-15 minutes or so. Try playing the save without DFhack a few times.
(0037839)
PatrikLundell (reporter)
2018-02-27 14:19
edited on: 2018-02-28 03:23

 Prior to this I've had about 3 DF crashes with this world, and I'm 18 years in, and it started in the last 5 or so. Anyway, I did get past the critical part(s), but I'll take up the advice and see what happens without DFHack (probably tomorrow) and report back.
Apart from the two bugs mentioned, it ought to be possible to see the non hostile visitor hostility mess by stationing a squad (e.g. 1) in the courtyard and then order an attack at the sneaker that's going to be detected. As far as I can tell, the visitor hostilities start when you get into a fight with the sneaker, not when it declares that it will attack you.

Edit:
I've rerun the save without DFHack a number of times:
- 3-4 times fighting broke out as a sneaker was detected and reached the courtyard (at which point I kill DF).
- 1 time the sneaker fled (I killed DF there).
- Twice DF died with Windows throwing up a box saying the application had died, contacting Microsoft, etc. Since I haven't seen that before (as in: the last year or so), I suspect this is the same root cause that causes the DFHack enabled game to just vanish, but DFHack somehow morphs the error symptom.

I've failed to get the second artifact demander to get to the meeting, as fighting broke out before that.
It can be noted that the detected sneaker isn't one of the huge group, but one out of two recent arrivals announced after the save: a bowman Shato and a lady consort (rather random which one and which entry they arrive through).

I'd forgotten to mention an additional raw change: the save has bananas yield wood, as without it they don't appear (separate bug report). I don't expect that to have anything to do with crashing, though.

There's also some minor freezing happening, one of which appears half a minute or so after the save is started (just 5 seconds or so).

Edit2: I managed to stall the hostile bowman by locking doors to send him back and forth between entrances, but the second demander trekked down the bowels of the fortress with "conduct meeting" displayed to the mayor, and then left without conducting any meeting (and without any report of a diplomat leaving disappointed, or whatever that description is). It can be noted that this took a fair while, and DF did NOT crash, so obviously crashing isn't 100% guaranteed.
(0037850)
PatrikLundell (reporter)
2018-03-03 06:19
edited on: 2018-03-30 16:27

 Rather than making a new bug report for what is probably the same crash, I add a save with a clearer crash. It's the same fortress with LNP r03. In this case it crashed twice with DFHack. I then disabled DFHack and it crashed 4 out of 4 times at exactly the same place. As with the previous crash, the DFHack enabled version had DF and DFHack just vanish, while without DFHack I get a Microsoft popup.

The save: https://www.dropbox.com/s/rs14194vbk0afsq/region6%20clear%20crash.zip?dl=0 [^]

To repeat the crash: Start the save, unpause, and cross your arms for less than two minutes. A crippled miner will carry a crutch to an injured kid in the hospital (west of the well). The miner will reach the lower tile of the two tile thick wall, at which time there's a sub section freeze before the popup appears. If that doesn't happen, the crash is probably configuration dependent.

Edit/Edit 2: Removed, as it was completely incorrect.
Edit 3: At a guess, it's related to revealing information. Using the DFHack command "exterminate her" on the latest arrival Destis "Quester" Ogsetoc stopped the crash from happening, and so did attacking her as she entered the courtyard.

Edit 4: The save does not crash with 0.44.06, so I guess the report is overtaken by events.

Edit 5: The saves had to be removed from Dropbox to make room for the latest bug report save. I still have the saves for the time being, but they would have to be requested.

- Issue History
Date Modified Username Field Change
2018-02-27 10:53 PatrikLundell New Issue
2018-02-27 12:02 PatrikLundell Note Added: 0037835
2018-02-27 12:34 Orkel Note Added: 0037837
2018-02-27 14:19 PatrikLundell Note Added: 0037839
2018-02-28 02:51 PatrikLundell Note Edited: 0037839 View Revisions
2018-02-28 03:23 PatrikLundell Note Edited: 0037839 View Revisions
2018-03-03 06:19 PatrikLundell Note Added: 0037850
2018-03-03 06:58 PatrikLundell Note Edited: 0037850 View Revisions
2018-03-03 12:34 PatrikLundell Note Edited: 0037850 View Revisions
2018-03-03 13:22 PatrikLundell Note Edited: 0037850 View Revisions
2018-03-04 03:01 PatrikLundell Note Edited: 0037850 View Revisions
2018-03-10 09:59 PatrikLundell Note Edited: 0037850 View Revisions
2018-03-30 16:27 PatrikLundell Note Edited: 0037850 View Revisions

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker