Sins Crashes - How to do a Backtrace

If Sins crashes and you'd like to help the developers figure out why it crashed this is how you do it.

When Sins crashes you usually get a core file. Check your sins executable directory for a core file "ls core*".

If you don't have a core file then your distro probably has core file generation turned off, to turn it back on you can type this "ulimit -c 99999" and go do what you did to make Sins crash again. If you'd like core file generation to remain on you may need to put "ulimit -c 99999" into your /etc/rc.local file, exact startup file depends on your distro but /etc/rc.local is present on most distros.

Now that you have a core file you want to open it in gdb with this command "gdb -c core sins", this assumes the name of your core file is core and the name of your sins exectuable is sins, both must be in the current directory. Some distros add pid's onto the end of the core file so it might be something like core.3184

gdb should load up the core file and print out this message to confirm that the core file was generated with the sins executable "Core was generated by './sins'". Look over what you see for any warnings or errors, these usually indicate something is wrong and the backtrace will not be useful.

You may have to hit the enter key a few time to get to the bottom of the symbol loading. Now all you have to do is type "bt" and hit enter and you will get something that looks like this:

#0 0x080a4e15 in DepthSlider::paintSlider ()
(gdb) bt
#0 0x080a4e15 in DepthSlider::paintSlider ()
#1 0x080a4e32 in DepthSlider::paintSlider ()
#2 0x080a4e32 in DepthSlider::paintSlider ()
#3 0x080a4e32 in DepthSlider::paintSlider ()
#4 0x080a4e32 in DepthSlider::paintSlider ()
#5 0x080a4e32 in DepthSlider::paintSlider ()

You may get more then this but all we want is the first bunch of lines just as you see here.

We also want to see any command line errors you got when sins crashed, often it will just say segfault and nothing useful but take a look.

Now go to the Sins help forum, desribe what you did that caused Sins to crash, if Sins acted oddly in any way before crashing, if there were any command line errors you can post those also and at the end post this output from the backtrace. Also tell us what distro you're using, whether Sins has ran fine for you before and if so what you did to make it start crashing. If you've never used Sins before let us know if you've successfully used Showeq before also.

Thanks for you quality feedback, it may help improve Sins for everyone.

This usually means you need to specify where QT is.

If you have no idea where QT is, here's several ways to find out:

1. Type this:
whereis qt2

And you might get something like this:
qt2: /usr/lib/qt2 /usr/include/qt2

Then the correct configure command would be this:
./configure --with-Qt-dir=/usr/qt/2

2. Or Try this:
cd /
locate *libqt-mt.so.*

It will give you some output like this:
/usr/qt/2/lib/libqt-mt.so.2
/usr/qt/2/lib/libqt-mt.so.2.3.2

For someone with output like this they'd type
./configure --with-Qt-dir=/usr/qt/2

3. Or try this:
cd /usr
find | grep libqt-mt.so

And your output might look like this:
./qt/2/lib/libqt-mt.so.2
./qt/2/lib/libqt-mt.so
./qt/2/lib/libqt-mt.so.2.3.2

Now we have to add "/usr" to the beginning since we started our search from there so once again a person with this output would type this:
./configure --with-Qt-dir=/usr/qt/2

Now if _none_ of these found QT then you probably don't have QT installed so you'll need to install it. QT versions known to work are 2.3.1, 2.3.2 or 3.0.3, other version may work but I haven't personally tried them recently.

This usually means you didn't put libEQ.a into /usr/lib just like it says. libEQ.a is case sensitive and the md5sum must match the one given on the installation page.

If you compiled QT yourself make sure you compiled QT with thread support
./configure --with-threads"

Environment variables may need setting. Edit the $HOME/.bash_profile (or $HOME/.profile depending on distro) and add something _similar_ to the following but correctly identifying the location of these files:

QTDIR=/usr/local/qt
PATH=$QTDIR/bin:$PATH
MANPATH=$QTDIR/doc/man:$MANPATH
LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

export QTDIR PATH MANPATH LD_LIBRARY_PATH

"source $HOME/.bash_profile" should update this information, otherwise just log out and back in.

This is often caused by using a wrong libEQ.a
Make sure your libEQ.a md5sum is the same one that's listed on the installation page. Use "locate libEQ.a" if you think you may have more then one copy on your drive.

If you've used Sins before and all of a sudden it isn't working move your sins directory somewhere else temporarily "mv /usr/local/share/sins /usr/local/share/sins-temp", then run "./make install" again, rename the fresh sins.conf.dist file to sins.conf and try running sins again with this fresh configuration file. If it doesn't fix the problem you can copy the old stuff back, if it does then you know it has something to do with your config files.

Sins is pretty fast but if you're running it on a low end system here are some suggestions to speed it up:

When you compile Sins make sure you use some optimized CXXFLAGS as described on the installation page

If you're low on memory (less then 64M) use a lightweight window manager like blackbox.

If your desktop color depth is higher then 16bit set it to 16bit

Make sure you're using the best video drivers for your card, if there are no good video drivers in linux for your card consider buying a new one. This is only the case if you can literally watch your windows be drawn when you move them around and it's not from hard drive access.

Right click on the map window and untick "animate spawn movement"

Decrease the FPS on your map window or your spawn list window.

Decrease the size of your map window.

GCC3 caused this for me while using mandrake 8.1, reverting to the original version of gcc fixed it.