Difference between revisions of "Bug Reporting"

From FreeSpace Wiki
Jump to: navigation, search
(additions and link fixes etc)
Line 1: Line 1:
 
== Places to ask about or report bugs ==
 
== Places to ask about or report bugs ==
  
[http://lore.maxgaming.net/~scp/mantis/main_page.php Mantis bug reporting system]
+
[http://scp.indiegames.us/mantis/login_page.php Mantis bug reporting system]
 
<br>[http://www.hard-light.net/smf/index.php/board,11.0.html FSSCP Forums]
 
<br>[http://www.hard-light.net/smf/index.php/board,11.0.html FSSCP Forums]
 
<br>[http://scp.indiegames.us/forum.php FSSCP Backup Forums]
 
<br>[http://scp.indiegames.us/forum.php FSSCP Backup Forums]
Line 8: Line 8:
  
 
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.
 
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.
 +
<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).
 +
<br><br>
 +
3. ALWAYS post what command lines you're using (And which ones the bug happens with).
 +
<br><br>
 +
4. ALWAYS post what graphics options you are using (OpenGL/D3D).
 +
<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 ==
  
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).
+
Especially when using debug builds, Freespace 2 will generate files called "errorlog.txt" and "fs.log".  
  
3. ALWAYS post what command lines you're using (And which ones the bug happens with).
+
=== errorlog.txt ===
  
4. 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.
+
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).
 +
<br><br>
 +
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".
 +
<br><br>
 +
Often the only useful information from the "errorlog.txt" is found from the first line of the corresponding entry.
  
5. 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.
+
==== Example ====
  
6. 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).
+
*The first chunk from a "errorlog.txt" entry
  
7. 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.
+
<pre>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.</pre>
  
8. Make sure to include what mediaVPs you're using.
+
*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.
  
== Posting error logs ==
 
  
Especially when using debug builds, Freespace 2 will generate files called "errorlog.txt" and "fs.log". 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).
+
=== fs.log ===
  
Additionally, posting the last five lines or so of "fs.log" can also be handy. Note that Notepad will not display it properly, so you'll have to open it up in Wordpad to view it properly.
+
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 12:41, 24 January 2007

Places to ask about or report bugs

Mantis bug reporting system
FSSCP Forums
FSSCP Backup 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 "fs.log".

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.


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.

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.

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.