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?