[webkit-dev] Obtaining backtraces

Michael Orlitzky michael at orlitzky.com
Fri Sep 6 14:48:36 PDT 2024


I spent the entire day today figuring out how to get a backtrace from
the installed copy of webkit-gtk. But I don't _just_ want to complain.
I'd like to figure out a way to do this easily, and to update the
documentation. The existing docs,

  https://trac.webkit.org/wiki/WebKitGTK/Debugging

are pretty misleading:

  * Core dumps don't happen any more because of bubblewrap
  * WEBKIT2_PAUSE_WEB_PROCESS_ON_LAUNCH quietly does nothing
    unless you happen to have built with DEVELOPER_MODE (won't
    be the case on a linux distro)
  * The minibrowser isn't going to be available on a distro, and if
    you aren't using the minibrowser, gdb won't follow the
    right children...
  * And you can't reliably guess the right PID of a running
    process quick enough to attach to it in e.g. epiphany.

Rebuilding from a git checkout and hacking on the webkit source to
enable DEVELOPER_MODE or the minibrowser is not always feasible. (Or
desirable -- I want to debug the code that is actually crashing, and
not spend three days guessing!) I've been dealing with crashes on my
laptop for years because it has very little RAM -- it simply doesn't
have the resources to build a development copy of webkit-gtk. Even now,
on a system with 64 low-power cores, it still takes more than a day,
and that's after spending half the day figuring out how to configure
the build exactly like the distro does, so that you can reproduce the
crash.

So for starters: is there something I missed? Some easy way to get a
traceback from a modern, system copy of webkit-gtk?

One idea: how hard would it be to skip bubblewrap in a release build if
some environment variable is set?




More information about the webkit-dev mailing list