Difference between revisions of "Debugger"
m |
|||
Line 13: | Line 13: | ||
== What to report == | == What to report == | ||
When odamex crashes, the first thing a developer wants to know from a debugger is where exactly it crashed. This is referred to as the "call stack" or "back trace". In gdb, you can type "bt" to get it. When you post a [[bugs|bug]] about a [[crash]], be sure to include this! | When odamex crashes, the first thing a developer wants to know from a debugger is where exactly it crashed. This is referred to as the "call stack" or "back trace". In gdb, you can type "bt" to get it. When you post a [[bugs|bug]] about a [[crash]], be sure to include this! | ||
+ | |||
+ | __NOTOC__ |
Revision as of 19:26, 30 March 2006
When a program crashes, you will typically get a crude and unhelpful message such as "Segmentation Fault" or "This program has performed an illegal operation". Reproducing a crash may be very difficult, and posting a bug related to such a crash is largely a waste of time. If a developer can't reproduce a crash, it cannot be fixed.
To catch each and every crash, it is recommended that developers and testers always run odamex with a debugger. This is a piece of software that can 'catch' crashes and provide very useful developer information.
Debuggers
gdb
VC6
Visual C++ has a built-in debugger. You must use the debug build for debugging to work. Use the debug menu to launch odamex in debug mode. If you have ran odamex from outside the debugger and it crashed, you can still attach the to the crashed process if you do not dismiss the crash dialog.
Code::Blocks
What to report
When odamex crashes, the first thing a developer wants to know from a debugger is where exactly it crashed. This is referred to as the "call stack" or "back trace". In gdb, you can type "bt" to get it. When you post a bug about a crash, be sure to include this!