[Vimprobable-users] [HOWTO] Debugging Vimprobable with Valgrind
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
From: Hans-Peter D. <hpd...@gm...> - 2011-10-16 14:04:22
|
Hi, Valgrind is a nice tool to debug memory leaks. Here is what I had to do to make it work well with vimprobable and in particular webkit: To run vimprobable under valgrind, use the following command: G_SLICE=always-malloc G_DEBUG=gc-friendly \ valgrind --leak-check=full --suppressions=valgrind_suppressions.supp \ --demangle=no --smc-check=all --num-callers=50 \ --log-file=valgrind.out ./vimprobable2 G_SLICE and G_DEBUG are there to make glib more valgrind friendly and are explained at [1]. The various options I used are: --leak-check=full: Give details about every leak --suppressions: Suppress errors that are unrelated to vimprobable. I will attach this file. --demangle=no: Webkit is C++ and thus uses mangled C-symbols. Valgrind shouldn't try to print the demangled symbols, because we need the mangled ones for the suppressions file. --smc-check=all: Detect self-modifying code. This is needed for Webkits JIT-compiler. --num-callers=50: Webkit and glib have very deep stack-traces. Show as much as possible of them. Regarding the suppressions file: Without it, valgrind shows many errors and leaks in libraries that are not caused by vimprobable. I tried to suppress all "definitely lost" warnings, that are not vimprobable's fault. I didn't do anything about "possibly lost" messages, because I'm unsure where most of them come from. You can skip them for now and concentrate on "definitely lost". I tested this (especially the suppressions file) only on one system, so it could happen that your system shows entirely different errors. You would have to write your own suppressions in this case. Also, I certainly didn't exercise all code paths with my testing, so there could be many more leaks lingering. HP [1]: http://developer.gnome.org/glib/2.28/glib-running.html -- Hans-Peter Deifel |