Debugging Tips

From Gnash Project Wiki

1 Random tips for debugging
2 Debugging Gstreamer media handler

Random tips for debugging

Note: when gnash executables run using libtool (usually when Gnash has not been installed and is running from the source directory), all debugging tools must be run with libtool --mode=execute. The executable file gnash is just a shell script that invokes the proper binary file, so you need to specify gtk-gnash, kde-gnash, fb-gnash etc. Examples:

libtool --mode=execute gdb --args gui/gtk-gnash -r1 mymovie.swf

libtool --mode=execute valgrind gui/fb-gnash mymovie.swf

Compile-time setup

Build with -D_GLIBCPP_DEBUG and -D_GLIBCXX_DEBUG to have the STL containers check boundary access. The two versions are for different stdlibc++ versions.
Disable threading to see how that changes behaviour of the bug you're facing. For movie loading this is done undefining the LOAD_MOVIES_IN_A_SEPARATE_THREAD in server/parser/movie_def_impl.cpp. For media handling and XML/LoadVars it's partially done by undefining THREADED_LOADS in libbase/LoadThread.h (something is likely missing). We'd need a generic macro to enable/disable ALL threading.
Make the GC run at every iteration rather then waiting for some new stuff being allocated. This is GC::maxNewCollectablesCount.
See if changing optimization flags fixes the issue (-O0)

Runtime setup

Export GLIBCPP_FORCE_NEW to make the STL release memory earlier rather then cache for reuse later
Run with valgrind to catch memory faults. libtool --mode=execute gui/gtk-gnash ....
Disable sound handling and see if the bug is still there (gnash -r1). If not, disable rendering and keep sound (-r2).
Try with another renderer/gui combination

Target movie edits

Make the bug-triggering movie as small as possible. You can use swfmill to change the structure of the movie, flasm to modify the action bytecodes and adding early traces.