Closed jeturcotte closed 9 years ago
Does 0.5 work?
Mods shouldn't effect things. I hardcode nothing for exactly that purpose.
I'll give 0.5 a swing; and glad to hear about that JapaMala... I'll see if I can get better details from the crash other than a guess on my part.
Walp, I tried again. With 0.5, there's no crash... just, no connectivity with the df-hack API, either, I assume. No doubt I'm simply doing something wrong, but the instructions given have been followed. Is it possible that remotefortressreader.cpp (referred to in that repo as a plugin) not present, or not enabled in some way?
Your remotefortressreader plugin is most likely not up-to-date. hack/plugins/remotefortressreader.plug.dylib is the compiled plugin (which probably came with DFHack r3), and remotefortressreader.cpp is the source code. I'll compile a build for OS X when I get a chance.
Walp, tried it... back to crashing ( of df, that is. ) I even tried it with a fresh unmodified version of the game as well, just to remove that potentiality: https://www.youtube.com/watch?v=XmnF937T2_k ... also tried, afterward, renaming the file away from X-osx.plug.dylib to X.plug.dylib, but behavior was the same.
From the unfettered install, a stderr.log:
2015-07-06 16:48:20.778 dwarfort.exe[7342:2956284] Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.
Jul 6 16:48:20 Joshuas-MacBook-Pro.local dwarfort.exe[7342]
(which did not SEEM terribly erroneous.)
On the modded:
Enabled tweak stable-cursor (stable_cursor_hook::feed) Enabled tweak advmode-contained (advmode_contained_hook::feed) Enabled tweak fast-trade (fast_trade_assign_hook::feed) Enabled tweak fast-trade (fast_trade_select_hook::feed) Enabled tweak military-stable-assign (military_assign_hook::feed) Enabled tweak military-color-assigned (military_assign_hook::render) Enabled tweak craft-age-wear (craft_age_wear_hook::ageItem) Enabled tweak farm-plot-select (farm_select_hook::feed) Enabled tweak farm-plot-select (farm_select_hook::render) Enabled tweak import-priority-category (takerequest_hook::feed) Enabled tweak import-priority-category (takerequest_hook::render) Enabled tweak civ-view-agreement (civ_agreement_view_hook::render) Enabled tweak fps-min (fps_min_hook) Enabled tweak max-wheelbarrow (max_wheelbarrow_hook::render) Enabled tweak max-wheelbarrow (max_wheelbarrow_hook::feed) Enabled tweak shift-8-scroll (shift_8_scroll_hook::feed) Enabled tweak tradereq-pet-gender (pet_gender_hook::render) Stockflow is now enabled. DFHack is ready. Have a nice day! Type in '?' or 'help' for general help, 'ls' to see all commands. [DFHack]# /Users/jeturcotte/Desktop/dwarf.24/dfhack: line 15: 10048 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
and unmodded:
ditto: [DFHack]# /Users/jeturcotte/Desktop/df_osx/dfhack: line 15: 7342 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
This all using 0.5 with the proffered dylib file.
Just tried subbing in the remotefortressreader.plug.dylib
from the release and it's also segfaulting for me:
[DFHack]# ./dfhack: line 15: 63280 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
Just so you know, that error message essentially says nothing more than "Dwarf Fortress crashed and DFHack was in use". Can you try remotefortressreader-osx-v2.plug.dylib.bz2 from the v0.5 release? (Also, you're decompressing these files, right?)
@lethosor Yes, decompressed and using that binary from the 0.5 release.
I tried compiling dfhack but ran into other issues (happened with Xcode 6.4 gcc/g++ as well as clang): https://gist.github.com/qrush/20c3caf5ddd1156f7cd3
Aye, that's the impression I got, as well (that it wasn't that useful an error message.) I just had nothing else to offer. At work now, so it'll be a while before I can try anything further.
On Tue, Jul 7, 2015 at 9:31 AM, Lethosor notifications@github.com wrote:
Just so you know, that error message essentially says nothing more than "Dwarf Fortress crashed and DFHack was in use". Can you try remotefortressreader-osx-v2.plug.dylib.bz2 from the v0.5 release? (Also, you're decompressing these files, right?)
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/issues/21#issuecomment-119202975 .
~jet
@qrush You know, I've had that exact error before and I have no idea how I solved it. It might have been something to do with gcc versions?
Also, are y'all using the most recent DF release?
FWIW, I develop on Yosemite and it works fine for me.
In my case, yes... the most recent.
On Tue, Jul 7, 2015 at 3:58 PM, James Gilles notifications@github.com wrote:
@qrush https://github.com/qrush You know, I've had that exact error before and I have no idea how I solved it. It might have been something to do with gcc versions?
Also, are y'all using the most recent DF release?
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/issues/21#issuecomment-119317797 .
~jet
I can test out v0.5 when I get home.
Yes, most recent DF.
On Tue, Jul 7, 2015 at 4:08 PM, James Gilles notifications@github.com wrote:
I can test out v0.5 when I get home.
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/issues/21#issuecomment-119320590 .
@qrush I missed your earlier comment, but you cannot use clang to compile DFHack; you have to use GCC 4.5 or newer (and if you're using a newer version, you might need to update DF's libstdc++). "gcc" included with XCode is usually clang, but there's also "gcc-4.2" which might be GCC but is too old to work.
The "v2" build of the plugin I put up simply does nothing in GetBuildingDefList(), which is where @fricy's crash report on the forums pointed to. I'm not actually sure if that will fix the problem or not. My plugins are all compiled with GCC 4.5 on OS X 10.9, though, so I doubt it's a compiler issue.
@lethosor ok - I was just trying to compile dfhack so I could maybe get closer to a working remotefortressreader. Maybe it needs to be recompiled, rereleased? What OSX are you building that on?
GCC 4.5 on OS X 10.9
Anyway, have either of you tried the "v2" plugin? (It's attached to the v0.5 release as well for now.)
That worked! Thanks @lethosor !
All right, I've replaced the original plugin with it. According to Japa, the data returned by that function isn't actually used by Armok Vision currently, so not sending it shouldn't cause problems.
It's not used yet but it will be used in the future, so this is still a bug that needs to be fixed.
This shows up in stderr.log with the buggy plugin:
terminate called after throwing an instance of 'DFHack::Error::NullPointer'
what(): DFHack::Error::NullPointer
Edit: This is #5, actually. Here's a more accurate traceback:
3 libstdc++.6.dylib 0x0295d5d9 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) + 23
4 remotefortressreader.plug.dylib 0x0e8b1bb9 std::string DFHack::format_key<short>(char const*, short) + 57
5 remotefortressreader.plug.dylib 0x0e8abbbc GetBuildingDefList(DFHack::color_ostream&, dfproto::EmptyMessage const*, RemoteFortressReader::BuildingList*) + 3308
6 remotefortressreader.plug.dylib 0x0e8af9d6 DFHack::ServerFunction<dfproto::EmptyMessage, RemoteFortressReader::BuildingList>::execute(DFHack::color_ostream&) + 54
7 libdfhack.1.0.0.dylib 0x0220650e DFHack::ServerConnection::threadFn() + 2046
8 libdfhack.1.0.0.dylib 0x02206d22 DFHack::ServerConnection::threadFn(void*) + 18
9 libdfhack.1.0.0.dylib 0x022b8477 tthread::thread::wrapper_function(void*) + 23
10 libsystem_pthread.dylib 0x9bd095fb _pthread_body + 144
11 libsystem_pthread.dylib 0x9bd09485 _pthread_struct_init + 0
12 libsystem_pthread.dylib 0x9bd0ecf2 thread_start + 34
The crash is occurring here, when trying to decode furnace type 49, which is strange because the loop should stop at 7. Here's the output of some debugging statements:
st = 0
ENUM_KEY_STR(furnace_type, st).c_str() = WoodFurnace
st = 1
ENUM_KEY_STR(furnace_type, st).c_str() = Smelter
st = 2
ENUM_KEY_STR(furnace_type, st).c_str() = GlassFurnace
st = 3
ENUM_KEY_STR(furnace_type, st).c_str() = Kiln
st = 4
ENUM_KEY_STR(furnace_type, st).c_str() = MagmaSmelter
st = 5
ENUM_KEY_STR(furnace_type, st).c_str() = MagmaGlassFurnace
st = 6
ENUM_KEY_STR(furnace_type, st).c_str() = MagmaKiln
st = 7
ENUM_KEY_STR(furnace_type, st).c_str() = Custom
st = 8
ENUM_KEY_STR(furnace_type, st).c_str() = FLOODGATE
st = 9
ENUM_KEY_STR(furnace_type, st).c_str() = HATCH_COVER
st = 10
ENUM_KEY_STR(furnace_type, st).c_str() = GRATE
st = 11
ENUM_KEY_STR(furnace_type, st).c_str() = DOOR
st = 12
ENUM_KEY_STR(furnace_type, st).c_str() = CATAPULTPARTS
st = 13
ENUM_KEY_STR(furnace_type, st).c_str() = BALLISTAPARTS
st = 14
ENUM_KEY_STR(furnace_type, st).c_str() = TRAPPARTS
st = 15
ENUM_KEY_STR(furnace_type, st).c_str() = BED
st = 16
ENUM_KEY_STR(furnace_type, st).c_str() = TRACTION_BENCH
st = 17
ENUM_KEY_STR(furnace_type, st).c_str() = WINDOW
st = 18
ENUM_KEY_STR(furnace_type, st).c_str() = CHAIR
st = 19
ENUM_KEY_STR(furnace_type, st).c_str() = TABLE
st = 20
ENUM_KEY_STR(furnace_type, st).c_str() = COFFIN
st = 21
ENUM_KEY_STR(furnace_type, st).c_str() = STATUE
st = 22
ENUM_KEY_STR(furnace_type, st).c_str() = SLAB
st = 23
ENUM_KEY_STR(furnace_type, st).c_str() = QUERN
st = 24
ENUM_KEY_STR(furnace_type, st).c_str() = MILLSTONE
st = 25
ENUM_KEY_STR(furnace_type, st).c_str() = ARMORSTAND
st = 26
ENUM_KEY_STR(furnace_type, st).c_str() = WEAPONRACK
st = 27
ENUM_KEY_STR(furnace_type, st).c_str() = CABINET
st = 28
ENUM_KEY_STR(furnace_type, st).c_str() = ANVIL
st = 29
ENUM_KEY_STR(furnace_type, st).c_str() = BUCKET
st = 30
ENUM_KEY_STR(furnace_type, st).c_str() = BIN
st = 31
ENUM_KEY_STR(furnace_type, st).c_str() = BOX
st = 32
ENUM_KEY_STR(furnace_type, st).c_str() = SIEGEAMMO
st = 33
ENUM_KEY_STR(furnace_type, st).c_str() = BARREL
st = 34
ENUM_KEY_STR(furnace_type, st).c_str() = BALLISTAARROWHEAD
st = 35
ENUM_KEY_STR(furnace_type, st).c_str() = PIPE_SECTION
st = 36
ENUM_KEY_STR(furnace_type, st).c_str() = FOOD_STORAGE
st = 37
ENUM_KEY_STR(furnace_type, st).c_str() = MINECART
st = 38
ENUM_KEY_STR(furnace_type, st).c_str() = WHEELBARROW
st = 39
ENUM_KEY_STR(furnace_type, st).c_str() = OTHER_LARGE_TOOLS
st = 40
ENUM_KEY_STR(furnace_type, st).c_str() = SAND_BAG
st = 41
ENUM_KEY_STR(furnace_type, st).c_str() = ?41?
st = 42
ENUM_KEY_STR(furnace_type, st).c_str() = ?42?
st = 43
ENUM_KEY_STR(furnace_type, st).c_str() = ?43?
st = 44
ENUM_KEY_STR(furnace_type, st).c_str() = ?44?
st = 45
ENUM_KEY_STR(furnace_type, st).c_str() = ?45?
st = 46
ENUM_KEY_STR(furnace_type, st).c_str() = ?46?
st = 47
ENUM_KEY_STR(furnace_type, st).c_str() = ?47?
st = 48
ENUM_KEY_STR(furnace_type, st).c_str() = layers_slow
st = 49
That is very strange indeed. It seems to be an overflow of some sort.
On Mon 13 Jul, 2015 8:54 pm Lethosor notifications@github.com wrote:
The crash is occurring here https://github.com/DFHack/dfhack/blob/a8bea3684ae2965029c8b5a36ab2aa380c440890/plugins/remotefortressreader.cpp#L981, when trying to decode furnace type 49, which is strange because the loop should stop at 7. Here's the output of some debugging statements:
st = 0 ENUM_KEY_STR(furnace_type, st).c_str() = WoodFurnace st = 1 ENUM_KEY_STR(furnace_type, st).c_str() = Smelter st = 2 ENUM_KEY_STR(furnace_type, st).c_str() = GlassFurnace st = 3 ENUM_KEY_STR(furnace_type, st).c_str() = Kiln st = 4 ENUM_KEY_STR(furnace_type, st).c_str() = MagmaSmelter st = 5 ENUM_KEY_STR(furnace_type, st).c_str() = MagmaGlassFurnace st = 6 ENUM_KEY_STR(furnace_type, st).c_str() = MagmaKiln st = 7 ENUM_KEY_STR(furnace_type, st).c_str() = Custom st = 8 ENUM_KEY_STR(furnace_type, st).c_str() = FLOODGATE st = 9 ENUM_KEY_STR(furnace_type, st).c_str() = HATCH_COVER st = 10 ENUM_KEY_STR(furnace_type, st).c_str() = GRATE st = 11 ENUM_KEY_STR(furnace_type, st).c_str() = DOOR st = 12 ENUM_KEY_STR(furnace_type, st).c_str() = CATAPULTPARTS st = 13 ENUM_KEY_STR(furnace_type, st).c_str() = BALLISTAPARTS st = 14 ENUM_KEY_STR(furnace_type, st).c_str() = TRAPPARTS st = 15 ENUM_KEY_STR(furnace_type, st).c_str() = BED st = 16 ENUM_KEY_STR(furnace_type, st).c_str() = TRACTION_BENCH st = 17 ENUM_KEY_STR(furnace_type, st).c_str() = WINDOW st = 18 ENUM_KEY_STR(furnace_type, st).c_str() = CHAIR st = 19 ENUM_KEY_STR(furnace_type, st).c_str() = TABLE st = 20 ENUM_KEY_STR(furnace_type, st).c_str() = COFFIN st = 21 ENUM_KEY_STR(furnace_type, st).c_str() = STATUE st = 22 ENUM_KEY_STR(furnace_type, st).c_str() = SLAB st = 23 ENUM_KEY_STR(furnace_type, st).c_str() = QUERN st = 24 ENUM_KEY_STR(furnace_type, st).c_str() = MILLSTONE st = 25 ENUM_KEY_STR(furnace_type, st).c_str() = ARMORSTAND st = 26 ENUM_KEY_STR(furnace_type, st).c_str() = WEAPONRACK st = 27 ENUM_KEY_STR(furnace_type, st).c_str() = CABINET st = 28 ENUM_KEY_STR(furnace_type, st).c_str() = ANVIL st = 29 ENUM_KEY_STR(furnace_type, st).c_str() = BUCKET st = 30 ENUM_KEY_STR(furnace_type, st).c_str() = BIN st = 31 ENUM_KEY_STR(furnace_type, st).c_str() = BOX st = 32 ENUM_KEY_STR(furnace_type, st).c_str() = SIEGEAMMO st = 33 ENUM_KEY_STR(furnace_type, st).c_str() = BARREL st = 34 ENUM_KEY_STR(furnace_type, st).c_str() = BALLISTAARROWHEAD st = 35 ENUM_KEY_STR(furnace_type, st).c_str() = PIPE_SECTION st = 36 ENUM_KEY_STR(furnace_type, st).c_str() = FOOD_STORAGE st = 37 ENUM_KEY_STR(furnace_type, st).c_str() = MINECART st = 38 ENUM_KEY_STR(furnace_type, st).c_str() = WHEELBARROW st = 39 ENUM_KEY_STR(furnace_type, st).c_str() = OTHER_LARGE_TOOLS st = 40 ENUM_KEY_STR(furnace_type, st).c_str() = SAND_BAG st = 41 ENUM_KEY_STR(furnace_type, st).c_str() = ?41? st = 42 ENUM_KEY_STR(furnace_type, st).c_str() = ?42? st = 43 ENUM_KEY_STR(furnace_type, st).c_str() = ?43? st = 44 ENUM_KEY_STR(furnace_type, st).c_str() = ?44? st = 45 ENUM_KEY_STR(furnace_type, st).c_str() = ?45? st = 46 ENUM_KEY_STR(furnace_type, st).c_str() = ?46? st = 47 ENUM_KEY_STR(furnace_type, st).c_str() = ?47? st = 48 ENUM_KEY_STR(furnace_type, st).c_str() = layers_slow st = 49
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/issues/21#issuecomment-120966608 .
It appears to be this GCC bug, where comparisons to an enum's maximum value are optimized out - I assumed it had been patched in GCC 4.5.4, but apparently that's not the case.
I managed to work around the compiler issue in the DFHack core - it was only occurring for a small number of enums, one of which happened to be furnace_type
. I won't upload a build for now because the fix requires rebuilding nearly all of DFHack (and could require updating all of DFHack, rather than just the plugin). The plugin I uploaded should still work with Armok Vision 0.5, since the code that was crashing isn't used by it.
Ahoy. This may be a known thing for you, or something you shouldn't even have to worry about, but I thought I'd make contact just it case it WAS of interest. But I tried this out recently with 0.4 and could not get it to start. However, my current game has custom raws... a few new animals... a couple new stones (meteorite, jasper, etc.) If I had to guess I'd say this was just because you can't possibly code well for what people MIGHT do to their raws.