Difference between revisions of "Debugging ScummVM"

Line 48:

[https://code.google.com/p/alogcat/]<br>

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, ...) ===

When debugging on Unix, the main tool is the GNU debugger:

[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 "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 GNU Data Display Debugger makes this easier:

[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:

[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 "valgrind --leakcheck=full ./scummvm".

For further details, you should consult the relevant documentation of these tools on their web sites or manual pages.

== Tips ==

Difference between revisions of "Debugging ScummVM"

Navigation menu

Search

@@ Line 48: / Line 48: @@
 [https://code.google.com/p/alogcat/]<br>
 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, ...) ===
+When debugging on Unix, the main tool is the GNU debugger:
+[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 "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 GNU Data Display Debugger makes this easier:
+[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:
+[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 "valgrind --leakcheck=full ./scummvm".
+For further details, you should consult the relevant documentation of these tools on their web sites or manual pages.
 == Tips ==