Open main menu

Difference between revisions of "Debugging ScummVM"

173 bytes added ,  05:20, 11 May 2013
m
(→‎Platform Specific Debugging: Add Unix Debugging (gdb/valgrind))
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.
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.
For further details, you should consult the relevant documentation of these tools on their web sites or manual pages.
2,051

edits