Stonesense fails to update view on Linux

[ase1590]

System: Arch Linux 64 bit version: dfhack 0.44.12-r1

attempting to load stonesense via ssense or stonesense after loading a map causes stonesense to not load in any visualizations, leaving a blue screen. The coordinate numbers on stonesense are the only thing that continue to update in response to keyboard controls.

Loading stonesense prior to loading a map allows stonesense to work for about 10 seconds before it totally freezes up.

After that, no commands are able to be input into the dfhack console, regardless of whether stonesense is closed or not. dwarffortress continues to run, but must be shut down and restarted in order to re-enable console commands.

stderr.log: http://ix.io/1pkT

Video of the issue: https://youtu.be/CSJoFzJLjAg

edit: this still occurs in 2019

[ghost]

Having the exact same issues, on the exact same system. Arch Linux 64-bit, dfhack 0.44.12-r1.

[mordrax]

Ubuntu bionic bever 64bit dfhack 0.44.12-r1

On Ubuntu bionic bever and starting via 'ssense' whilst df was on the main menu causes system to become unresponsive. I had to force restart as no keys, mouse would respond.

[nethershaw]

Ditto to all. Is there any way at all to get some logging or debug traces out of stonesense so that we can at least see what it's trying to do when it goes out to lunch for no apparent reason?

[lethosor]

I wish there were, but it's probably something to do with Allegro, which is mostly beyond our control.

[bendlas]

I once tried to debug this, and I'm pretty sure, that it has to do with missing graphics assets. No idea, though, why it wouldn't affect other platforms the same way ...

[Ram-Z]

Does it maybe have something to do with case sensitive filesystems on Linux? Other platforms will happily load a file with mismatching case, but Linux will not.

Note that I have not had any look at this at all.

On Jul 27, 2019 at 15:50, Herwig Hochleitner wrote:

I once tried to debug this, and I'm pretty sure, that it has to do with missing graphics assets. No idea, though, why it wouldn't affect other platforms the same way ...

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/DFHack/stonesense/issues/64#issuecomment-515718853

[adri326]

I am having the same issue on Arch Linux, having built the latest version, all I get is a single render once I load the world, then no updates whatsoever. The only thing I noticed is some dark outline moving when pressing > or <.

[nandryshak]

I'm also having this issue on Arch Linux.

Looks like the tiletype_list_ is empty when stonesense tries to look for materials?

(gdb) bt
#0  0x00007ffff67daf25 in raise () at /usr/lib/libc.so.6
#1  0x00007ffff67c4897 in abort () at /usr/lib/libc.so.6
#2  0x00007ffff6d5a81d in __gnu_cxx::__verbose_terminate_handler() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff6d674da in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x00007ffff6d67537 in std::terminate() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x00007ffff6d6778e in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))
    (obj=<optimized out>, tinfo=0x7ffff679c4b8 <typeinfo for google::protobuf::FatalException>, dest=0x7ffff676daf6 <google::protobuf::FatalException::~FatalException()>)
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x00007ffff676d514 in google::protobuf::internal::LogMessage::Finish() (this=0x7fff189207e0)
    at /home/nick/builds/dfhack/depends/protobuf/google/protobuf/stubs/common.cc:195
#7  0x00007ffff676d564 in google::protobuf::internal::LogFinisher::operator=(google::protobuf::internal::LogMessage&) (this=0x7fff189207df, other=...)
    at /home/nick/builds/dfhack/depends/protobuf/google/protobuf/stubs/common.cc:203
#8  0x00007fff6618ccee in google::protobuf::internal::RepeatedPtrFieldBase::Get<google::protobuf::RepeatedPtrField<RemoteFortressReader::Tiletype>::TypeHandler>(int) const
    (this=0x7fff4c001e98, index=215) at /home/nick/builds/dfhack/depends/protobuf/google/protobuf/repeated_field.h:659
#9  0x00007fff6618c802 in google::protobuf::RepeatedPtrField<RemoteFortressReader::Tiletype>::Get(int) const (this=0x7fff4c001e98, index=215)
    at /home/nick/builds/dfhack/depends/protobuf/google/protobuf/repeated_field.h:860
#10 0x00007fff6618c61e in RemoteFortressReader::TiletypeList::tiletype_list(int) const (this=0x7fff4c001e90, index=215)
    at /home/nick/builds/dfhack/plugins/proto/RemoteFortressReader.pb.h:10133
#11 0x00007fff6618c204 in Tile::tileMaterial() (this=0x7ffed4256d60) at /home/nick/builds/dfhack/plugins/stonesense/Tile.cpp:852
#12 0x00007fff661dd944 in readMaterialToTile(Tile*, unsigned int, unsigned int, df::map_block*, DFHack::t_feature const&, DFHack::t_feature const&, std::vector<df::block_square_event_mineralst*, std::allocator<df::block_square_event_mineralst*> > const&, std::vector<std::vector<short, std::allocator<short> >, std::allocator<std::vector<short, std::allocator<short> > > >*)
    (b=0x7ffed4256d60, lx=14, ly=15, trueBlock=0x7ffeed3e0280, local=..., global=..., veins=std::vector of length 0, capacity 0, allLayers=0x7fff18920bd0)
    at /home/nick/builds/dfhack/plugins/stonesense/MapLoading.cpp:262
#13 0x00007fff661de978 in readBlockToSegment(DFHack::Core&, WorldSegment&, int, int, int, unsigned int, unsigned int, unsigned int, unsigned int, std::vector<std::vector<short, std::allocator<short> >, std::allocator<std::vector<short, std::allocator<short> > > >*)
    (DF=..., segment=..., BlockX=3, BlockY=5, BlockZ=167, BoundrySX=0, BoundrySY=0, BoundryEX=15, BoundryEY=15, allLayers=0x7fff18920bd0)
    at /home/nick/builds/dfhack/plugins/stonesense/MapLoading.cpp:585
#14 0x00007fff661dfb86 in readMapSegment(WorldSegment*, GameState) (segment=0x7fff74b59750, inState=...) at /home/nick/builds/dfhack/plugins/stonesense/MapLoading.cpp:875
#15 0x00007fff661e0231 in read_segment(void*) (arg=0x0) at /home/nick/builds/dfhack/plugins/stonesense/MapLoading.cpp:1010
#16 0x00007fff661e0310 in threadedSegment(ALLEGRO_THREAD*, void*) (read_thread=0x7ffed8c12b00, arg=0x0) at /home/nick/builds/dfhack/plugins/stonesense/MapLoading.cpp:1034
#17 0x00007fff7c09262a in  () at /usr/lib/liballegro.so.5.2
#18 0x00007fff7c0ccd4b in  () at /usr/lib/liballegro.so.5.2
#19 0x00007ffff66d64cf in start_thread () at /usr/lib/libpthread.so.0
#20 0x00007ffff689e2d3 in clone () at /usr/lib/libc.so.6
(gdb) f 10
#10 0x00007fff6618c61e in RemoteFortressReader::TiletypeList::tiletype_list (this=0x7fff4c001e90, index=215)
    at /home/nick/builds/dfhack/plugins/proto/RemoteFortressReader.pb.h:10133
10133     return tiletype_list_.Get(index);
(gdb) p tiletype_list_
$9 = {
  <google::protobuf::internal::RepeatedPtrFieldBase> = {
    static kInitialSize = 4,
    elements_ = 0x7fff4c001eb0,
    current_size_ = 0,
    allocated_size_ = 0,
    total_size_ = 4,
    initial_space_ = {[0] = 0xd2d2d2d2d2d2d2d2, [1] = 0xd2d2d2d2d2d2d2d2, [2] = 0xd2d2d2d2d2d2d2d2, [3] = 0xd2d2d2d2d2d2d2d2}
  }, <No data fields>}

edit: I put a breakpoint in stonesense ContentLoader:103, materialNameList.material_list_size() is 0. So I guess stonesense isn't getting the materials, etc. from RemoteFortressReader?

edit2: okay so just ignore this comment.... I had web server for work already open on port 5000 so dfhack couldn't bind to that port.... Stonesense still isn't working though.

edit3: wtf! my locally compiled stonesense/dfhack doesn't work, but the linux release version does... I can't believe I lost all that time debugging when it was my work api server all along. Oh well, at least losing is fun.

[adri326]

This seems to no longer be an issue with the latest versions (dfhack v0.47.05-r1 (release)).

[lethosor]

@ase1590 does this still occur for you with DFHack 0.47.05-r2 (or newer)?

[ase1590]

@lethosor Just tested this again on 0.47.05-r2 and this seems to be fixed now :)

thanks!

issue can be closed!