# Advanced debugging

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.

## Where does it crash ?

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.

## Other problems

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