Deploying WebKit, common issues

Deploying WebKit, common issues

From my exposure to people deploying QtWebKit or WebKit/GTK+ there are some things that re-appear and I would like to discuss these here.
  • Weird compile error in JavaScript?
    • It is failing in JavaScriptCore as it is the first that is built. It is most likely that the person that provided you with the toolchain has placed a config.h into it. There are some resolutions to it. One would be to remove the config.h from the toolchain (many things will break), or use -isystem instead of -I for system includes.
    The best way to find out if you suffer from this problem is to use -E instead of -c to only pre-process the code and see where the various includes are coming from. It is a strategy that is known to work very well.
  • No pages are loaded.
    • Most likely you do not have a DNS Server set, or no networking, or the system your board is connected to is not forwarding the data. Make sure you can ping a website that is supposed to work, e.g. ping www.yahoo.com, the next thing would be to use nc to execute a simple HTTP 1.1 get on the site and see if it is working. In most cases you simply lack networking connectivity.
  • HTTPS does not work
    • It might be either an issue with Qt or an issue with your system time. SSL Certificates at least have two dates (Expiration and Creation) and if your system time is after the Expiration or before the Creation you will have issues. The easiest thing is to add ntpd to your root filesystem to make sure to have the right time.
    The possible issue with Qt is a bit more complex. You can build Qt without OpenSSL support, you can make it link to OpenSSL or you can make it to dlopen OpenSSL at runtime. If SSL does not work it is most likely that you have either build it without SSL support, or with runtime support but have failed to install the OpenSSL library.
    Depending on your skills it might be best to go back to ./configure and make Qt link to OpenSSL to avoid the runtime issue. strings is a very good tool to find out if your libQtNetwork.so contains SSL support, together with using objdump -x and search for _NEEDED you will find out which config you have.
  • Local pages are not loaded
    • This is a pretty common issue for WebKit/GTK+. In WebKit/GTK+ we are using GIO for local files and to determine the filetype it is using the freedesktop.org shared-mime-info. Make sure you have that installed.
  • The page only displays blank
    • This is another issue that comes back from time to time. It only appears on WebKit/GTK+ with the DirectFB backend but sadly people never report back if and how they have solved it. You could make a difference and contribute back to the WebKit project.
    In general most of these issues can be avoided by using a pre-packaged Embedded Linux Distribution like Ångström (or even Debian). The biggest benefit of that approach is that someone else made sure that when you install WebKit, all dependencies will be installed as well and it will just work for your ARM/MIPS/PPC system. It will save you a lot of time.
    Taking over memprof

    Taking over memprof

    Where did all my memory go? Who is allocating it, how much is being allocated? From where were theses QImages allocated? valgrind provides an accurate leak checker, but for a running application you might want to know about allocations and browse through them and don’t take the performance hit of valgrind (e.g with massif).

    There is an easy way to answer these questions, use memprof. memprof used to be a GNOME application, it was unmaintained, the website was gone from the net, but this tool is just way too good to just drop out of the net. After trying to reach the maintainer twice I decided to adopt the orphaned thing.

    Check the application out, it is great, it helps me to get an overview of memory allocations for WebKit/GTK+…

    First ever Gtk+ patch

    First ever Gtk+ patch

    During my work on Epiphany I was debugging a problem with the “woohoo” bar. It took me not less than three days to understand the issue, write a test case, and a patch and put everything in this bug. Matthias Clasen was kind enough to review and commit the patch and it can be found here. Sadly the –author tag of git was not used and the commit does not carry my name, so ohloh will not list my contribution to Gtk+.

    The main issue with debugging was finding signal connections, e.g. which function is connected to that signal and which objects, and figuring out what was called during the signal activation. My approach was the usual printf method in many places and adding _backtrace() to function calls using the glibc builtin backtracing functionality. I would like to have SystemTap at a state I could use it for tracing, or be able to script gdb (it has python plugin support now) to automatically execute a trigger when certain parts of the code got executed.

    Anyway, I’m happy to have fixed a Gtk+ bug and being a contributor now.

    API Reference Manual for WebKit/Gtk+

    API Reference Manual for WebKit/Gtk+

    As of two days ago the Gtk+ buildbot is finally running the test suite after every build. And today we even have the first regressions that we need to address/understand. The short-, mid- and long term goal is now to get as many tests running as possible and keep them running. There are quite some bugs to be fixed in WebKit/Gtk+, our base libraries, our testing tools so there is plenty of fun left for everyone.

    In the webkit IRC channel we sometimes get questions regarding the API of the WebKit/Gtk+ port and if there are examples. On the one hand we are pretty strong. We have the GtkLauncher, some early adopters, when adding API many people made sure that we have API documentation. On the other hand we are weak as there is no introduction, no generated reference manual, no downloadable samples. So I got a bit sidetracked from the regression work and started to integrate gtk-doc and to cut a long story short: You can find an initial version here.

    On to the gory details. Integrating gtk-doc requires recursive make due the way the gtk-doc.make rules are written. This file is copied in from gtkdocize. When dealing with documentation you can not have srcdir != builddir. The html result will be put in the source directory and if you try to squeeze in the @VERSION@ you will need srcdir == builddir. Starting from GtkDoc in live.gnome.org and Florian’s GPE guide one finds pretty much everything one needs to find. Some things needed some look at the tool sourcecode (perl, eeek!) but are clear now.

    WEBKIT_API type
    function_name (function*…);

    To make gtkdoc-scan parse the above as a function you will need to pass –ignore-decorators=”WEBKIT_API” to the tool. Magically plenty of symbols turned up in the -unused.txt file and I was able to copy them into the -sections.txt. Now the tool refused to find any documentation. So remember WebKit/Gtk+ is mostly written in C++ and gtkdoc-mkdb simply does not know about the “.cpp” file extension. So pass –source-suffixes=c,cpp to gtkdoc-mkdb and it will find the sourcecode. Ah functions and their documentation, almost perfect. The last undocumented bit is for -sections.txt. E.g. you have the various _get_type(void) methods and there is little benefit of having them pop up in the API. Inside your “<SECTION>” you can put them into a “<SUBSECTION Private>” and they will be ignored.

    The next thing is to get it actually merged into WebKit and integrate having uptodate API reference in the release process.

    Link WebKit/Gtk+ faster

    Link WebKit/Gtk+ faster

    Last year in India Simon showed me an ancient and well hidden qmake feature. With this hidden feature you can easily move some files to a new library.

    Why is this good? Well, the new library only contains the files you are currently working on. In most of the cases this will be only a hand full. You will get blazing fast linking and round trip times if you do so.

    So today I worked on a issue with SVGFont.cpp and my roundtrip time was way too slow. So I decided to apply this hack to our superb autotools based buildsystem!

    So I have a hacky patch which is turning noinst libraries to normal libraries to avoid the running of ar/ranlib. I have created a libWebCoreHack.la, GtkLauncher and DumpRenderTree link to that library now. And you have to move the sources you work on from webcore_sources to webcorehack_sources. With this hack I have almost instant turn around times again.

    How to use it: Whenever you work on a area move the usual suspects to the webcorehack_sources, relink once and then you can benefit from the fast link times.

    *happy*