Print

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

[peterix]

I have the exact same problem with the same OS. Tried 4018 40d18HEAD and 40d19. When I start dwarf therapist, df crashes with segmentation fault.

See:

Just wanted to mention for those of you trying the linux version for d18-d19, the creature vector offset was incorrect.  Please replace the existing Memory.xml in the /etc folder of dwarf therapist with the one at peterix's github

Click on raw and save the Memory.xml file into DT's etc/ folder.

[muty]

Thanks for the fast reply, that was it.

I was pretty sure I overwrote the file, but apparently I didn't.

I'm a happy dwarf now

[kutulu]

Ok, I've spent the past 8 hours trying to get dwarf therapist to connect to DF with zero success.  It consistently exhibits the same behavior: it locks up attempting to connect to the running instance of DF and stays locked up until I kill DT, which then causes DF to segfault.

I've tried running the binaries from github, as well as building my own local copies, and get the exact sale behavior in every case.

I'm using Gentoo amd64, running DF 40d19.  Does anyone recognize what might be going on here?  DF is unplayable for me without a management program to manage labors :\

--K

[peterix]

Ok, I've spent the past 8 hours trying to get dwarf therapist to connect to DF with zero success.  It consistently exhibits the same behavior: it locks up attempting to connect to the running instance of DF and stays locked up until I kill DT, which then causes DF to segfault.
Does anyone recognize what might be going on here?

Yes, see the few posts before yours.

[Petr Ga]

Hi Balal and peterix

can you please repack dwarf therapist with latest peterix dfhack version?
it should allow to start stonesense and therapist simultaneously.

otherwise, it runs perfectly for me on 40d19.2

[kutulu]

Ok, I've spent the past 8 hours trying to get dwarf therapist to connect to DF with zero success.  It consistently exhibits the same behavior: it locks up attempting to connect to the running instance of DF and stays locked up until I kill DT, which then causes DF to segfault.
Does anyone recognize what might be going on here?

Yes, see the few posts before yours.

I already replaced the Memory.xml file with the one from the github, it didn't help.

--K

[peterix]

I already replaced the Memory.xml file with the one from the github, it didn't help.

--K

Well, I can't replicate the error. Everything seems to work as it should, even with a big and old fort like Reinhammers.

So, let's try a few things

First:
Verify that it runs without the libdfconnect lib in DF. just rename it or something. DT won't be able to write creature nicknames and custom professions, but it should at least rule out problems with bad Memory.xml.

If this works and the data looks good (no garbage or crashes), try using the current precompiled libdfconnect.so from git.

If that still scrashes, I'd like to get a backtrace. The library is built with debug symbols, so a debugger should show relevant data

The process of getting that looks like this:

Spoiler (click to show/hide)

Open a terminal in DF's folder.
Type:

Code: [Select]

export SDL_DISABLE_LOCK_KEYS=1
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"./libs"
export LD_PRELOAD="./libs/libdfconnect.so" # this is the SHM lib
gdb ./dwarfort.exe
You should end up with gdb waiting for your input.
Type:

Code: [Select]

run
Now DF is running in the debugger.
Start DT from its folder, using its start script

Code: [Select]

./start_dwarftherapist
Now switch back to the terminal with gdb and observe the results.
If it crashes, type:

Code: [Select]

backtraceAnd send me the output.

DT can be run in gdb as well. The process is similar.

Code: [Select]

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"."
gdb ./DwarfTherapist
Some useful gdb stuff:
CTRL+C breaks the execution of the currently debugged program.
Use q or quit to get out of gdb.

After you are done with the debugging, close the terminals. You shouldn't open anything else with the LD_LIBRARY_PATH and LD_PRELOAD set.

[Boatmurdered]

Small update with my problem. I found the missing library (libQtScript.so.4), and I put it in the same folder with Dwarf Therapist. I now run the program, and instead of giving me missing library problems, I'm getting an error saying wrong ELF Class:ELFCLASS64. I did some digging, and I know its due to me running 64-bit Ubuntu. However, the solutions I find don't do me any good.

Can anyone help me?

[peterix]

Well. You need to grab the 32bit version of that library.

This ubuntu bug seems related https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/490735

It's been fixed in Lucid, but not backported to the other releases. So, tell your distro maintainers

[Boatmurdered]

Well. You need to grab the 32bit version of that library.

This ubuntu bug seems related https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/490735

It's been fixed in Lucid, but not backported to the other releases. So, tell your distro maintainers

I had figured as such. But then, the solutions I had found were pasting the lib into /usr/lib32. Guess I should have been able to figure that out.

Now I'm just hunting down GLIBC_2.11 before I go to work.

[kutulu]

\\Verify that it runs without the libdfconnect lib in DF. just rename it or something. DT won't be able to write creature nicknames and custom professions, but it should at least rule out problems with bad Memory.xml.

If this works and the data looks good (no garbage or crashes), try using the current precompiled libdfconnect.so from git.

This seems to have fixed my problem.  Is this different from the dfconnect library that's in git in the dwarftherapist/precompiled/linux?  I'm pretty sure that's where I got the one I've been using this far.

It's also possible that I had mixed up the precompiled binaries with the ones I built myself.  Even with the working dfconnect library, the dfhack/dwarftherapist I built hangs on startup.  It looks like, even though dwarftherapist specifies -m32 in it's CFLAGS, that I'm getting 64-bit output anyway, since it won't link to the precompiled libdfhack.so.  Will 64-bit dfhack not share memory properly with the 32-bit dfconnect? 

--K

[peterix]

If this works and the data looks good (no garbage or crashes), try using the current precompiled libdfconnect.so from git.

This seems to have fixed my problem.  Is this different from the dfconnect library that's in git in the dwarftherapist/precompiled/linux?  I'm pretty sure that's where I got the one I've been using this far.

Good to hear that it works now
Yes, it's from a newer version of dfhack. And it was built on an Ubuntu machine, which is as close I can get to what Toady builds DF on. Linux binary compatibility is crazy.

Heavy linux dev talk follows.

Spoiler (click to show/hide)

It's also possible that I had mixed up the precompiled binaries with the ones I built myself.  Even with the working dfconnect library, the dfhack/dwarftherapist I built hangs on startup.  It looks like, even though dwarftherapist specifies -m32 in it's CFLAGS, that I'm getting 64-bit output anyway, since it won't link to the precompiled libdfhack.so.  Will 64-bit dfhack not share memory properly with the 32-bit dfconnect? 

--K

Building libdfconnect yourself/linking against precompiled stuff from other distros: Don't, unless you really know what you are doing. All it takes for it to fail is a simple change in alignment of C++ types or something similar. If I didn't have to hack in using LD_PRELOAD (if it was an official DF API), there would be no such problem, but the way things are right now, libdfconnect has to be binary compatible with DF. LD can detect some of the problems, but not all.
Mixing libs built with different compilers, libc/libstdc++ versions or CFLAGS is just asking for trouble... and that's probably why you can't link to the precompiled libdfhack.so

Anyway, when you build both DT and dfhack, it should work even with 64bit. Actually, I do this all the time - I'm using 64bit Archlinux and the Ubuntu machine is only for building libdfconnect

[Boatmurdered]

Still not working for me. I seem to have a bad version of the GNU C Library (I think that's what it's trying to tell me anyway).

Here's my output:

Code: [Select]

./DwarfTherapist: /lib32/libc.so.6: version 'GLIBC_2.11' not found (required by /usr/lib32/libQtGui.so.4)
./DwarfTherapist: /lib32/libc.so.6: version 'GLIBC_2.11' not found (required by /usr/lib32/libpng12.so.0)

I'll admit, I'm still pretty new to heavy Linux use, so I may be missing something.

[njero]

Quick reply to thank those who have picked up development on this tool. While I appreciate the effort Toady is putting into the in-game interface, I don't think I could ever play with >50 dwarves without an external manager.

Keep up the good work.

[Gontro]

Hey guys, I'm just curious as to whether a compiled binary for OSX is being worked on or planned in the future? 

I use my mac for work and usually have df running in the background.  Unfortunately there isn't any tools for dwarf management available for the mac (I use 40d16 and even the modified version of MacForeman error's on me).  I usually end up having to copy my save to a network share, restart my machine into windows, organise my dorfs, copy the save back to a network share, then restart back into mac.  As you can imagine this is quiet a tedious process