wiki:WebKitGTK/TrackingMemoryErrors

Version 11 (modified by Andres Gomez, 12 years ago) ( diff )

--

Tracking memory errors and leaks in WebKitGTK+

Tracking memory errors and leaks in WebKitGtk is similar to how is done for other GTK/GNOME software, with a few extra considerations.

The Valgrind page at GNOME wiki <​https://live.gnome.org/Valgrind> contains some tips, and is a useful reading as a starting point.

WebKit1

G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-modules valgrind \
    --tool=memcheck --leak-check=full --leak-resolution=high        \
    --num-callers=20 --log-file=vgdump --smc-check=all              \
    WebKitBuild/Release/Programs/GtkLauncher

Notice the --smc-check-all flag, which enables checks for self modifying code. This is needed because the JIT dynamically patches the generated code for some of it's optimizations.

WebKit2

G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-modules valgrind         \
    --tool=memcheck --leak-check=full --leak-resolution=high                \
    --num-callers=20 --log-file=vgdump --smc-check=all --trace-children=yes \
    WebKitBuild/Release/Programs/MiniBrowser

Here, the interesting bit is --trace-children=yes, which tells valgrind to also hook into any child process spawned by the original program. For WK2 this is required if you want to check memory in the Web process (which you most likely do), otherwise it will only check it in the UI process.

Notice that for both WK1 and WK2, the corresponding launcher programs are used instead of the provided script, in order to avoid checking for errors in the script's runtime, which apart from been undesired, will slow down the process even more.

List of memory leaks found in WebKit

List of memory leaks found in external modules

Note: See TracWiki for help on using the wiki.