We never debug our code, because we don't put bugs in. Okay, you want some real stuff. Sam still uses printf() to find out where it crashes. For real programmers, here is a summary of what you can do if you have problems. The best way to know that is to use gdb. You can start using it with good chances by configuring with --enable-debug . It will add -g to the compiler CFLAGS, and activate some additional safety checks. Just run gdb vlc, type run myfile.vob, and wait until it crashes. You can view where it stopped with bt, and print variables with print <C-style>. If you run into troubles, you may want to turn the optimizations off. Optimizations (especially inline functions) may confuse the debugger. Use --disable-optimizations in that case. It may be more complicated than that, for instance unpredictable behaviour, random bug or performance issue. You have several options to deal with this. If you experience unpredictable behaviour, I hope you don't have a heap or stack corruption (eg. writing in an unallocated space), because they are hard to find. If you are really desperate, have a look at something like ElectricFence or dmalloc. Under GNU/Linux, an easy check is to type export MALLOC_CHECK_=2 before launching vlc (see malloc(3) for more information). VLC offers a "trace-mode". It can create a log file with very accurate dates and messages of what it does, so it is useful to detect performance issues or lock-ups. Compile with --enable-trace and tune the TRACE_* flags in include/config.h to enable certain types of messages (log file writing can take up a lot of time, and will have side effects).