From Gnash Project Wiki
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
- 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)
- 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.
- For finding memory leaks, run valgrind with the flag --leak-check=full
Debugging Gstreamer media handler
See GstreamerDebugging page