Difference between revisions of "Debugging ScummVM"

Debugging ScummVM (view source)

Revision as of 05:20, 11 May 2013

173 bytes added , 05:20, 11 May 2013

m

→‎Unix (Linux, Solaris, OSX, ...): cleanup

Clone2727

2,051

edits

@@ Line 49: / Line 49: @@
 This requires no Host PC, USB connection or software setup beyond installing this app and can be downloaded from the Android Store (Google Play) for no cost.
-=== Unix (Linux, Solaris, OSX, ...) ===
+=== Unix (Linux, Solaris, Mac OS X, MinGW ...) ===
-When debugging on Unix, the main tool is the GNU debugger:
+When debugging on Unix, the main tool is the [http://www.gnu.org/software/gdb/ GNU debugger]. This can be invoked as <tt>gdb ./scummvm</tt>.
-[http://www.gnu.org/software/gdb/]
-This can be invoked as "gdb ./scummvm".
+Like most debuggers, if a crash (segfault) occurs, then control is returned to the debugger i.e. the gdb command prompt will appear. This then allows commands to be entered to query the state at the
+point of the crash. The most useful command is <tt>bt</tt> which prints a backtrace of the point of the crash, showing the function call stack state.
-Like most debuggers, if a crash (segfault) occurs, then control is
+Unless <tt>--enable-release</tt> is passed to configure, ScummVM will be compiled with debug symbols and the backtrace should be readable with annotations of ScummVM function names and line numbers.
-returned to the debugger i.e. the gdb command prompt will appear.
-This then allows commands to be entered to query the state at the
-point of the crash. The most useful command is "bt" which prints
-a backtrace of the point of the crash, showing the function call
-stack state.
-Unless --enable-release is passed to configure, scummvm will be compiled with debug symbols and the backtrace should be readable with annotations of scummvm function names and line numbers.
+If you want to use gdb for setting breakpoints, examining variables, then the graphical wrapper for gdb, called the [http://www.gnu.org/software/ddd/ GNU Data Display Debugger] makes this easier.
-If you want to use gdb for setting breakpoints, examining variables, then the graphical wrapper for gdb, called the GNU Data Display Debugger makes this easier:
+If the bug is suspected to be caused by memory management issues i.e. uninitialized variables, bad memory accesses, memory leaks or thread problems then a better tool is the [http://valgrind.org/ Valgrind instrumentation framework].
-[http://www.gnu.org/software/ddd/]
-If the bug is suspected to be caused by memory management issues i.e. unitialised variables, bad memory accesses, memory leaks or thread problems then a better tool is the Valgrind instrumentation framework:
+This can be invoked similar to gdb as <tt>valgrind ./scummvm</tt>. On Mac OS X, you will also want to pass the <tt>--dsymutil=yes</tt> argument so that you will get debug symbol information.
-[http://valgrind.org/]
-This can be invoked similar to gdb as "valgrind ./scummvm".
+By default, this will output memory access issues. If you want to do leak checking, you should invoke as <tt>valgrind --leakcheck=full ./scummvm</tt>.
-By default, this will output memory access issues. If you want to do leak checking, you should invoke as "valgrind --leakcheck=full ./scummvm".
 For further details, you should consult the relevant documentation of these tools on their web sites or manual pages.