Difference between revisions of "Bug Reporting"

From FreeSpace Wiki
Jump to: navigation, search
(additions and link fixes etc)
(Places to ask about or report bugs)
(6 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
== Places to ask about or report bugs ==
 
== Places to ask about or report bugs ==
  
[http://scp.indiegames.us/mantis/login_page.php Mantis bug reporting system]
+
* All new bugs are submitted here:
<br>[http://www.hard-light.net/smf/index.php/board,11.0.html FSSCP Forums]
+
**[https://github.com/scp-fs2open/fs2open.github.com/issues GitHub issues page]
<br>[http://scp.indiegames.us/forum.php FSSCP Backup Forums]
+
 
 +
* If you want to ask about bugs, you can do so on the forums:
 +
**[https://www.hard-light.net/forums/index.php/board,50.0.html FSSCP Forums]
  
 
== Basic Guidelines ==
 
== Basic Guidelines ==
  
1. Look before you leap - make sure there isn't a similar bug before you post a new one. If there is a similar bug, post info on your particular circumstance.
+
# Look before you leap - make sure there isn't a similar bug before you post a new one. If there is a similar bug, post info on your particular circumstance.
 +
# ALWAYS post what build you're using (If it's named something like "fs2_open_r", post where you got it from and what date it was posted).
 +
# ALWAYS post what command lines you're using (And which ones the bug happens with).
 +
# ALWAYS post what graphics options you are using (OpenGL/D3D).
 +
# Don't just post the bug. Post any and all relevant info, and if you aren't sure if something might be relevant - post it anyway.
 +
# If at all possible, post contact info. Nothing is more convenient for a dev than having an ICQ number you can use to talk with a person having a problem. It can also speed things up a lot.
 +
# If you've got the time, run a debug build and post any errors you get with it (Not all builds have a debug build with them though).
 +
# Keep track of any bugs you post (in)! Nothing is more annoying than not being able to close a bug simply because you don't know if it's solved or not.
 +
# Make sure to include what mediaVPs you're using.
 +
 
 +
== Error logs ==
 +
 
 +
Especially when using debug builds, FreeSpace 2 will generate files called "errorlog.txt" and more importantly "fs2_open.log" (new version of older "fs.log").
 +
 
 +
 
 +
=== fs.log OR fs2_open.log ===
 +
 
 +
These files - "fs.log" and "fs2_open.log" - are generally the same except the later is renamed and is placed into the main data directory instead of the root FreeSpace 2 directory (where the "fs.log" is placed)
 
<br><br>
 
<br><br>
2. ALWAYS post what build you're using (If it's named something like "fs2_open_r", post where you got it from and what date it was posted).
+
Debug build builds new "fs2_open.log" file every time its run - even when there is no problems encountered - so make sure to gather the relevant data before running the debug build again. Posting the last five lines or so of "fs2_open.log" can be handy. Note that Notepad will not display it properly, so you'll have to open it up in Wordpad to view it properly. Posting the "fs2_open.log" in its full extent is not very useful as it contains a lot of information that debug build reports there.
 
<br><br>
 
<br><br>
3. ALWAYS post what command lines you're using (And which ones the bug happens with).
+
In some cases it also helps to create an empty text file named "[[debug_filter.cfg]]" to the '''data''' directory under the 'root' FreeSpace 2 directory and then recreate the "fs2_open.log" file (that is to run debug build again) - with older "fs.log" file the "[[debug_filter.cfg]]" ought to be placed into 'root' FreeSpace 2 directory. This causes the debug build to gather a lot more data into the "fs2_open.log" file which may prove useful for debugging the actual issues. The "fs2_open.log" files created with "debug_filter.cfg" in use are easily over a megabyte in size often will not even open in Notepad.
 
<br><br>
 
<br><br>
4. ALWAYS post what graphics options you are using (OpenGL/D3D).
+
If you read the "fs2_open.log" file you may notice problematic sections by yourself as well but in general '''do not post the whole "fs2_open.log"''' file - just the last five or so lines. There are also other very important sections in the "fs2_open.log" file that may help in identifying the issues. Like the section that begins with '''Building file index...''' (search for this) and ends to '''Found 21 roots and 12326 files''' (numbers may vary) as it contains information of all the various vp files the game loads. Also other sections like OpenAL initialization or OpenGL/D3D initialization may be of some use
<br><br>
 
5. Don't just post the bug. Post any and all relevant info, and if you aren't sure if something might be relevant - post it anyway.
 
<br><br>
 
6. If at all possible, post contact info. Nothing is more convenient for a dev than having an ICQ number you can use to talk with a person having a problem. It can also speed things up a lot.
 
<br><br>
 
7. If you've got the time, run a debug build and post any errors you get with it (Not all builds have a debug build with them though).
 
<br><br>
 
8. Keep track of any bugs you post (in)! Nothing is more annoying than not being able to close a bug simply because you don't know if it's solved or not.
 
<br><br>
 
9. Make sure to include what mediaVPs you're using.
 
<br><br>
 
== Error logs ==
 
 
 
Especially when using debug builds, Freespace 2 will generate files called "errorlog.txt" and "fs.log".  
 
  
 
=== errorlog.txt ===
 
=== errorlog.txt ===
Line 50: Line 55:
 
*The first line - in this case '''fs2_open_r-P4 caused an Illegal Instruction in module fs2_open_r-P4.exe at 001b:005f11b7.''' - tells something about the error that occurred. It is also the line that ought to be included into to the error/bug reports.
 
*The first line - in this case '''fs2_open_r-P4 caused an Illegal Instruction in module fs2_open_r-P4.exe at 001b:005f11b7.''' - tells something about the error that occurred. It is also the line that ought to be included into to the error/bug reports.
  
 
=== fs.log ===
 
 
Debug build builds new "fs.log" file every time its run - even when there is no problems encountered - so make sure to gather the relevant data before running the debug build again. Posting the last five lines or so of "fs.log" can be handy. Note that Notepad will not display it properly, so you'll have to open it up in Wordpad to view it properly. Posting the "fs.log" in its full extent is not very useful as it contains a lot of information that debug build reports there.
 
<br><br>
 
In some cases it also helps to create an empty text file named "debug_filter.cfg" to the 'root' FreeSpace 2 directory and then recreate the "fs.log" file (that is to run debug build again). This causes the debug build to gather a lot more data into the "fs.log" file which may prove useful for debugging the actual issues. The "fs.log" files created with "debug_filter.cfg" in use are easily over a megabyte in size often will not even open in Notepad.
 
<br><br>
 
If you read the "fs.log" file you may notice problematic sections by yourself as well but in general '''do not post the whole "fs.log"''' file - just the last five or so lines.
 
  
 
[[Category:Source Code Project]]
 
[[Category:Source Code Project]]

Revision as of 21:36, 2 September 2018

Places to ask about or report bugs

  • If you want to ask about bugs, you can do so on the forums:

Basic Guidelines

  1. Look before you leap - make sure there isn't a similar bug before you post a new one. If there is a similar bug, post info on your particular circumstance.
  2. ALWAYS post what build you're using (If it's named something like "fs2_open_r", post where you got it from and what date it was posted).
  3. ALWAYS post what command lines you're using (And which ones the bug happens with).
  4. ALWAYS post what graphics options you are using (OpenGL/D3D).
  5. Don't just post the bug. Post any and all relevant info, and if you aren't sure if something might be relevant - post it anyway.
  6. If at all possible, post contact info. Nothing is more convenient for a dev than having an ICQ number you can use to talk with a person having a problem. It can also speed things up a lot.
  7. If you've got the time, run a debug build and post any errors you get with it (Not all builds have a debug build with them though).
  8. Keep track of any bugs you post (in)! Nothing is more annoying than not being able to close a bug simply because you don't know if it's solved or not.
  9. Make sure to include what mediaVPs you're using.

Error logs

Especially when using debug builds, FreeSpace 2 will generate files called "errorlog.txt" and more importantly "fs2_open.log" (new version of older "fs.log").


fs.log OR fs2_open.log

These files - "fs.log" and "fs2_open.log" - are generally the same except the later is renamed and is placed into the main data directory instead of the root FreeSpace 2 directory (where the "fs.log" is placed)

Debug build builds new "fs2_open.log" file every time its run - even when there is no problems encountered - so make sure to gather the relevant data before running the debug build again. Posting the last five lines or so of "fs2_open.log" can be handy. Note that Notepad will not display it properly, so you'll have to open it up in Wordpad to view it properly. Posting the "fs2_open.log" in its full extent is not very useful as it contains a lot of information that debug build reports there.

In some cases it also helps to create an empty text file named "debug_filter.cfg" to the data directory under the 'root' FreeSpace 2 directory and then recreate the "fs2_open.log" file (that is to run debug build again) - with older "fs.log" file the "debug_filter.cfg" ought to be placed into 'root' FreeSpace 2 directory. This causes the debug build to gather a lot more data into the "fs2_open.log" file which may prove useful for debugging the actual issues. The "fs2_open.log" files created with "debug_filter.cfg" in use are easily over a megabyte in size often will not even open in Notepad.

If you read the "fs2_open.log" file you may notice problematic sections by yourself as well but in general do not post the whole "fs2_open.log" file - just the last five or so lines. There are also other very important sections in the "fs2_open.log" file that may help in identifying the issues. Like the section that begins with Building file index... (search for this) and ends to Found 21 roots and 12326 files (numbers may vary) as it contains information of all the various vp files the game loads. Also other sections like OpenAL initialization or OpenGL/D3D initialization may be of some use

errorlog.txt

Posting the first chunk of data from the corresponding entry in errorlog.txt can be a big help, as it may tell the dev exactly what went wrong where. (This chunk is recognizable, as it should have the date and time that the crash occured).

Most recent 'crash report' is the last one that has been listed into the "errorlog.txt". If you encounter the crash repeatedly you might want to first remove the "errorlog.txt" file from the 'root' FreeSpace 2 directory and then run the game again. Then you get only single entry to the "errorlog.txt".

Often the only useful information from the "errorlog.txt" is found from the first line of the corresponding entry.

Example

  • The first chunk from a "errorlog.txt" entry
fs2_open_r-P4 caused an Illegal Instruction in module fs2_open_r-P4.exe at 001b:005f11b7.
Exception handler called in FreeSpace 2 Main Thread.
Error occurred at 1/14/2007 15:17:32.
E:\Games\FreeSpace2\fs2_open_r-P4.exe, run by Unknown.
1 processor(s), type 586.
1024 MBytes physical memory.
  • The first line - in this case fs2_open_r-P4 caused an Illegal Instruction in module fs2_open_r-P4.exe at 001b:005f11b7. - tells something about the error that occurred. It is also the line that ought to be included into to the error/bug reports.