Schism:Debugging
From SDWiki
Schism Tracker crashes that are cross-platform and "obvious" will probably be fixed within a few hours. This page is about a crash you have experienced. You are probably unique, or at least your situation is. Don't assume that the developers know about the bug that you experienced, or that they don't need your help. At the time of this writing, mrsbrisby uses Linux on a Thinkpad R61e laptop using the Xv/YUV driver, ALSA output, but OSS midi input, mostly non-looping samples, and almost never uses filters. Storlek uses either an AMD64 with Linux and the ALSA and Xv drivers, or a Powerbook with OpenGL/Quartz/CoreAudio; uses lots of tiny loops and filter tricks, avoids MIDI like the plague ;) and hardly ever uses instrument mode. Your situation is almost certainly different. This guide will help you determine exactly what is relevant.
[edit] Generic Instructions
- Try to reproduce the problem. Truly random crashes mean you have broken hardware (e.g. bad ram).
- Find the smallest number of steps that cause the crash.
- Does it happen with a particular song?
- If you press a particular set of keystrokes?
- Some time after doing some steps?
- How about a particular song file format? (Does it also happen to an XM file? An S3M?)
- Is it dependent on a particular sample format? (stereo samples? 8bit only? 16bit only? mixed?)
- What graphics and sound settings did Schism Tracker detect? (press Ctrl-F11 right after startup)
- What MIDI hardware was detected? (press Shift-F1)
- Did it happen with a different video driver? (press Ctrl-F1 and try the SDL Video driver)
- Does it happen with different settings (Shift-F5, F12, Ctrl-F1, and Shift-F1)?
- Ask the board if it happens to anyone else. At the very least, they can offer suggestions of other things to try.
[edit] Using a Distributor
- Debian and Ubuntu users should contact Simon Richter or Gürkan Sengün via the Debian Schism Tracker Project Page.
- Fedora users should contact Jindrich Novy.
The distro-packages tend to lag significantly behind live development. You should probably remove your schism or schismtracker package from your system and install packages from the downloads area if you have a problem to at the very least make sure yor bug hasn't already been fixed.
[edit] Using a Binary Build
- Record the date of the build. Its at the top of the window, and printed out when you run schismtracker --version from the command line.
- Linux can make core files, and running ulimit -c unlimited will cause programs to make core files; they're usually called core.pid.
- OS X offers a "crash dump" whenever a program crashes that was launched by the Finder.
Find the crash dump for Schism Tracker and post it on the development board.
[edit] Using Windows
- Download and install Microsoft Debug Diagnostic Tools
- Start Schism Tracker normally
- See How To Configure Microsoft Debug Diagnostic Tools
- Upload the complete html report someplace and post it to the development board
[edit] Building from Source
- Configure with --enable-debug. Try using --enable-ludicrous-mode as well — especially if you're on a system that isn't officially supported, this might hint at bugs that have been overlooked.
- Run under gdb or similar. Using a core file with debugging info is usually fine.
- Save a backtrace for all the threads.
Give as many details as possible: OS, compiler version, CPU type, etc. As above, post it on /scdev/.
[edit] How to help somebody else with a bug in Schism Tracker
- Check Impulse Tracker behavior. If it's a sound problem, make a test module, and use Impulse Tracker's own diskwriter, save as a sample in the module and use it to test Schism Tracker's behavior.
- Try to reproduce it. Obviously, if you can reproduce it, you can run through the build/test/debug cycle very quickly.
- If it's not an easy fix, create a new page on the wiki at least outlining the problem from a technical standpoint.
