| Version 7 (modified by , 11 years ago) ( diff ) |
|---|
Debugging WebKitGTK+
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 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.
