Debugging WebKitGTK+

We sure of checking first the generic instructions about debugging with GDB.

You need a compilation with symbols (take it easy as it'll take some time/hours):

$ Tools/Scripts/build-webkit --gtk --debug

On 32-bits arch it is quite unlikely this build will succeed. If you need a build with debug symbols but still without ASSERTs enabled you can try these options:

$ Tools/Scripts/build-webkit --gtk --disable-fast-malloc --enable-debug-symbols=full --disable-optimizations

In other to run GtkLauncher under gdb you should use a jhbuild shell and run gdb normally or use the jhbuild-wrapper as follows:

$ Tools/jhbuild/jhbuild-wrapper --gtk run gdb --args WebKitBuild/Debug/Programs/GtkLauncher

Logging support

Logging and other output/behaviors support is activated by default in a Debug build only.

In addition to having the logging support activated in the compilation, we need also to turn on the proper logging channels when running.

These channels are defined in the ​Source/WebCore/platform/Logging.h and ​Source/WebKit2/Platform/Logging.h headers in the code:

For passing the wanted channels to the running process we need to use the WEBKIT_DEBUG env variable as it is seen in the ​WebCore/platform/gtk/LoggingGtk.cpp and ​Source/WebKit2/Platform/gtk/LoggingGtk.cpp files in the code.

• Notice also the DISABLE_NI_WARNING env variable referred there.

It is important to export the WEBKIT_DEBUG env variable because you will want it to affect also the WeProcess.

• This is an example for turning on the logging int he Network channel. Notice that the channels are case insensitive.

  $ export WEBKIT_DEBUG="network"
  $ Tools/Scripts/run-minibrowser --gtk
  

It is also possible to turn on the logging and other output/behaviors support in a Release build by setting the proper C Macros. You may want to check the ​Source/WTF/wtf/Assertions.h header.

• This is a Release build example in which we want to turn on the logging support

  $ export CPPFLAGS="-DLOG_DISABLED=0"
  $ Tools/Scripts/build-webkit --gtk
  

Network analysis

Although libsoup should log everything we need about the network traffic in the GTK port, we may want to use other mechanisms to get that information because, for example, we don't have a build with logging support available in that moment.

Tools like ​tcpdump or ​WireShark can be handy in this case.

This is an example of tcpdump usage to get all the headers of the HTTP traffic going to an HTTP server running in the port 8000 of the loopback interface:

$ tcpdump -vvvs 1024 -l -A -i lo0 'tcp port 8000'

Debugging multimedia stuff

You can use the environment variable GST_DEBUG:

$ export GST_DEBUG="webkit*:5"

To debug a multimedia test inside DRT (Dump Render Tree):

$ Tools/Scripts/run-webkit-tests --gtk --additional-env-var=GST_DEBUG=webkit*:5 --additional-env-var=GST_DEBUG_NO_COLOR=1 http/tests/media/video-play-stall.html

Debugging tests

• In order to run tests inside the @jhbuild@ shell, these two environment variables must be set:

  $ export TEST_RUNNER_TEST_PLUGIN_PATH=$WEBKIT_HOME/WebKitBuild/Release/Libraries/.libs/
  $ export TEST_RUNNER_INJECTED_BUNDLE_FILENAME=$WEBKIT_HOME/WebKitBuild/Release/Libraries/libTestRunnerInjectedBundle.la
  

Debugging WebKit2

If you want to debug the web process, the simplest way is connecting to it using gdb:

$ gdb -p <pid of WebKitWebProcess>

However that doesn't work in all cases, because the web process might already have crashed when you are trying to connect to it.

You can use the WEB_PROCESS_CMD_PREFIX environment variable for that purpose. If that variable is defined the web process will be run using its value as a prefix.

Example:

WEB_PROCESS_CMD_PREFIX='/usr/bin/gdbserver localhost:8080' WebKitBuild/Debug/Programs/MiniBrowser

and in a different terminal:

$ libtool --mode=execute gdb WebKitBuild/Debug/Programs/WebKitWebProcess
(gdb) target remote localhost:8080

If you want to debug the network process you can use NETWORK_PROCESS_CMD_PREFIX in a similar way.

Note that these variables are only enabled in debug builds. If you still want to use them in release builds you can remove the relevant #ifndef NDEBUG in ProcessLauncherGtk.cpp, ProcessLauncher.h, WebProcessProxyGtk.cpp and NetworkProcessProxySoup.cpp

Debugging issues

• Some times when running the WebKitTestRunner (WK2) you can see linking errors like the following one:

  (lt-WebKitWebProcess:3392): WARNING **: Error loading the injected bundle (/home/javi/devel/WebKit/webkit.git/WebKitBuild/Debug/Libraries/libTestRunnerInjectedBundle.la): /home/javi/devel/WebKit/webkit.git/WebKitBuild/Debug/Libraries/.libs/libTestRunnerInjectedBundle.so: undefined symbol: _ZTVN7leveldb10ComparatorE
  

  • One possible cause of such errors are missing symbols in the Source/autotools/symbols.filter. These symbols are automatically exposed in the by the libWebCoreInternals library via tags. Such library expose some symbols for testing purposes, just like the WTR application does.
  • The symbols.filter should be updated by a fresh checkout, but if that's not the case, it's possible to workaround the issue by manually adding the missing symbols to the file.

Related

• Tips for debugging using GDB
• Tracking memory errors in WebKitGTK+