The Aleph One wiki has migrated! Please see:
What should you do if Aleph One crashes? Generally, you should inform the developers. Read this page for a general guide on how to file a bug report on Sourceforge.
Before submitting a report, make sure your bug hasn't already been fixed. Check the main page for the latest version of Aleph One. If your version is out of date, upgrade and try the same steps that led to the crash. Bugs reported for old versions will be ignored.
These are the two ways that Aleph One exits unexpectedly. Read the sections below for a description of each, and then continue on to learn how to determine which happened and what to add to your bug report.
These happen when Aleph One does an internal consistency check, and finds something so seriously wrong it can't continue. Assertion failures always print a message to the log file, but often they are in very generic places in the code so the message isn't always helpful.
If Aleph One quits because of an assertion failure, it will show up in the log file. Copy the assertion failure part of the log to the sourceforge bug report, or upload the relevant part of the log file.
Also, if you were in a solo game when Aleph One encountered an assertion failure, you can save a film of the assertion by starting Aleph One up, and choosing "Save Last Film". Attach the film to the bug report, and also the map if it's not a well-known or widely-available scenario.
The log file is located in your home directory's Library/Logs folder, named Aleph One Log.txt. If you're using an all-in-one build, then it will be named after the game, such as Marathon 2 Log.txt.
The log file is located in your "My Documents" folder, named Aleph One Log.txt. If you're using an all-in-one build, then it will be named after the game, such as Marathon 2 Log.txt.
The log file is located in your
~/.alephone directory, named Aleph One Log.txt. If you're using an all-in-one build, then it will be named after the game, such as Marathon 2 Log.txt.
Application crashes occur when the operating system performs a consistency check on Aleph One and finds something seriously wrong. Since they are unpredicted (unlike assertion failures) they don't print an error message to the log file. A crash reporting tool is necessary to figure out why Aleph One is crashing.
Mac OS X includes a built-in crash reporter, that will pop-up when Aleph One crashes. Click on "Report..." and you'll get a crash report. Attach that text to the bug you file.
It doesn't hurt to submit bugs to Apple. They often times can trace framework or other system-level crashes by using aggregate and other comparative tools. In short, Apple may not care about A1, but it still can provide them with useful crash data when looking at the "big picture". Apple encourages you to share reports with them whenever a program crashes.
In order to get crash reports in Windows, you need to copy this file to the same folder as Aleph One.exe, and try to get it to crash again. If it crashes, a TEST.RPT file will be saved. Attach TEST.RPT to the sourceforge bug.
You can run Aleph One in gdb:
$ gdb ./alephone (gdb) run -d
and when it crashes, type:
Copy the backtrace into the sourceforge bug report.