Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jecowa]

It doesn't seem very random that I could never generate a world older than 50 years without TBWT and I never had a problem while TWBT was installed. I didn't just try to generate a single world without TWBT. I tried multiple times changing world gen parameters to see if lowering world size or history size could help. On the second day, I did at least 4 tries of generating a world without TWBT. I wanted the largest size to work and expected it too, so I tried that first. Then tested with a pocket world. Then tested will full DFHack. Then tried switching just the Print_Mode to TWBT without installing TWBT. And on the first day of testing, I generated at least 4 worlds with TWBT+Meph, all of those generated 100+ years and never crashed or froze. Even with just those 9 tests, if the game has a 50% chance of working, it'd be a 0.390625% chance that it would have only worked while using TWBT in those tests.

[lethosor]

Even with just those 9 tests, if the game has a 50% chance of working, it'd be a 0.390625% chance that it would have only worked while using TWBT in those tests.

I should have been clearer with my choice of words: I'm not suspecting a "random" issue, but one that is not caused by the things you're changing. Your math assumes that crashes are independent, which they aren't necessarily. Just last week I ran into a crash that occurred almost always on Windows and almost never on Linux, even though the source code of DF+DFHack+plugins was the same. To re-emphasize part of my earlier post, I suspect that the crash you're seeing

becomes harder to reproduce with certain combinations of shared objects (either libraries or plugins) loaded.

i.e. certain combinations may affect whether a certain crash occurs, but do not necessarily cause or fix said crash.

Do you have any crash reports from these crashes?

Then tried switching just the Print_Mode to TWBT without installing TWBT.

This is identical to [PRINT_MODE:STANDARD], by the way. I would be more interested in knowing if you get crashes with TWBT installed but PRINT_MODE set to something else (e.g. STANDARD); that could help narrow down whether TWBT simply being loaded into memory has an impact.

[jecowa]

No errorlogs were ever generated. There was nothing interesting in the gamelogs either.

I'm not entirely sure if it ever crashed. It was freezing during at least most the worldgens yesterday. I kind of thought it was crashing on the first day, though, but not sure.

[lethosor]

No errorlogs were ever generated. There was nothing interesting in the gamelogs either.

Oh, sorry, I'm referring to crash reports generated by macOS, not by DF. These sometimes come up in a "dwarfort.exe has quit unexpectedly" dialog, but depending on your settings, you might need to find them in the Console app. A couple links to what I'm referring to:
https://support.apple.com/guide/console/reports-cnsl664be99a/mac
https://apple.stackexchange.com/questions/26480/where-can-i-find-my-crash-logs

I'm not entirely sure if it ever crashed. It was freezing during at least most the worldgens yesterday. I kind of thought it was crashing on the first day, though, but not sure.

Wait, a crash and a freeze aren't the same thing at all. By "crash" I am only referring to instances of DF closing completely, and usually a "dwarfort.exe has quit unexpectedly" dialog (depending on your settings). Is that not what you were talking about this whole time? (If DF isn't crashing after all, you wouldn't have macOS-generated crash reports, and it would seem that your experience is different than what's described in the bug report I was interested in.)

[jecowa]

Oh, sorry, I'm referring to crash reports generated by macOS, not by DF. These sometimes come up in a "dwarfort.exe has quit unexpectedly" dialog, but depending on your settings, you might need to find them in the Console app.

Thanks, I'll check for those next time.

Wait, a crash and a freeze aren't the same thing at all. By "crash" I am only referring to instances of DF closing completely, and usually a "dwarfort.exe has quit unexpectedly" dialog (depending on your settings). Is that not what you were talking about this whole time? (If DF isn't crashing after all, you wouldn't have macOS-generated crash reports, and it would seem that your experience is different than what's described in the bug report I was interested in.)

I think Adventure Mode might have been crashing. I kind of think that World Gen was crashing too. I'll pay more attention to that next time. Maybe Tuesday.

[jecowa]

I think maybe I was getting actual crashes with pure vanilla, but the next day when I tried with the DFHack libstdc, I got freezes instead. I'll try to test that later today and get console.app logs.

[jecowa]

Double-clicking "DF" instead of "DFHack" is the same as running vanilla, right?

• Vanilla (Print_Mode: STANDARD) - freezes on world creation
• Vanilla but with DFHack's libstdc (Print_Mode: STANDARD) - freezes on world creation
• DFHack+TWBT, but with Print_Mode set to "STANDARD" - "crashes" on world creation

Nothing comes up in Console.app's log that I can see. The operating system does not generate a crash report; Dwarf Fortress seems to exit without a proper crash (which is unusual considering Dwarf Fortress always crashes when exiting out of the game).

There is some interesting stuff in the Terminal window, though, from when it crashes (or maybe just stops running) during world gen:

Spoiler: DFHack Terminal window (click to show/hide)

guest@MacBook-Pro ~ % /DF_v0.47.05_DFHack+TWBT/dfhack ; exit;
dfhack: attempting to hook in
Loading bindings from data/init/interfact.txt
Resetting textures
Plugin twbt was not built for this version of DFHack.
Plugin: 0.47.04-alpha0, DFHack 0.47.05-r1
Cannot initialize ruby plugin: failed to load ruby library
^[^[
The dfhack.init configuration file is missing. To customize your DFHack installation, rename the dfhack.init-example file to dfhack.init and edit it to suit your needs.

For now, dfhack.init-example will be used instead.

Press ENTER or ESC in the DF window to continue...
^[DFHack is ready. Have a nice day!
DFHack version 0.47.05-r1 (release) on x86_64
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]# /DF_v0.47.05_DFHack+TWBT/dfhack: line 27: 5109 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]▉

[lethosor]

Double-clicking "DF" instead of "DFHack" is the same as running vanilla, right?

Yes, it should be (except on Windows).

• Vanilla (Print_Mode: STANDARD) - freezes on world creation
• Vanilla but with DFHack's libstdc (Print_Mode: STANDARD) - freezes on world creation
• DFHack+TWBT, but with Print_Mode set to "STANDARD" - "crashes" on world creation

At what point do these freezes occur? Immediately when selecting "Create new world", right when worldgen starts, after a couple years, when attempting to save the world, or something else?

Code: [Select]

[DFHack]# /DF_v0.47.05_DFHack+TWBT/dfhack: line 27: 5109 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"


This line definitely indicates a crash ("Segmentation fault" and "Bus error" are the key phrases to look for). Where are you looking in Console.app? The main log window won't have crash reports; you will need to find crash reports in another place, probably in the sidebar. https://eshop.macsales.com/blog/45586-how-to-use-the-mac-console-app-to-diagnose-a-crash/ appears to have a more recent screenshot, but I'm not sure if it exactly matches macOS 11.

[jecowa]

• Vanilla (Print_Mode: STANDARD) - freezes on world creation
• Vanilla but with DFHack's libstdc (Print_Mode: STANDARD) - freezes on world creation
• DFHack+TWBT, but with Print_Mode set to "STANDARD" - "crashes" on world creation

At what point do these freezes occur? Immediately when selecting "Create new world", right when worldgen starts, after a couple years, when attempting to save the world, or something else?

On that particular day, they were at years 7, 11, and 18. The time frame for the freezes seems to be the same as for the crash. Oh, I just noticed that even on the freezes in vanilla it goes through that cycle with "Saving session… copying shared history… [Process completed]". It doesn't mention the segfault, though.

Code: [Select]

[DFHack]# /DF_v0.47.05_DFHack+TWBT/dfhack: line 27: 5109 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"


This line definitely indicates a crash ("Segmentation fault" and "Bus error" are the key phrases to look for). Where are you looking in Console.app? The main log window won't have crash reports; you will need to find crash reports in another place, probably in the sidebar. https://eshop.macsales.com/blog/45586-how-to-use-the-mac-console-app-to-diagnose-a-crash/ appears to have a more recent screenshot, but I'm not sure if it exactly matches macOS 11.

Console changed in Big Sur. I might not have had access to the tab that gives the relevant info.

Spoiler: Big Sur Console.app (click to show/hide)

That stuff in the "Devices" section required an admin password.

[lethosor]

Try "Log Reports" or "Diagnostic Reports"? Failing that, they should be in ~/Library/Logs (note that ~/Library may be hidden) and have a .crash extension, unless that has also changed in macOS 11.

[jecowa]

Is this the type of thing that I should be looking for when I try again (maybe on Sunday)?

Code: [Select]

Process:               dwarfort.exe [45618]
Path:                  /Applications/Lazy Mac Pack v0.47.05 dfhack-r1/*/dwarfort.exe
Identifier:            dwarfort.exe
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        sh [45611]
Responsible:           dwarfort.exe [45618]
User ID:               501

Date/Time:             2021-03-23 14:03:34.855
OS Version:            Mac OS X 10.14.5 (18F132)
Report Version:        12

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [45618]It also includes a bunch of stack trace, register states, and loaded binaries (not posted above).
The above is from an Intel Mac, btw. Probably a crash-on-quit crash log.

[lethosor]

Yep! And as a last resort, this should be able to find any that exist:

Code: [Select]

find ~/Library -name '*.crash'


[jecowa]

Sorry, I think it requires an admin password in Big Sur. Both ~/Library/Logs/DiagnosticReports/ and /Library/Logs/DiagnosticReports/ need elevated permissions to open. I searched the entire drive for any files that contain ".crash" and made sure it includes both system files and invisible files in the results. No crash logs came up.

[Alphum5]

Is it possible to find out exactly what apple changed with Big Sur 11.1+ and would it be useful in the rehabilitation of DF on Big Sur?

[Thisfox]

I'm not sure whether rehabilitation is necessary if the game works just fine on Big Sur?