Bug 146246 - [GTK] Empty gtk-font-name setting causes WebProcess crash rendering pages
Summary: [GTK] Empty gtk-font-name setting causes WebProcess crash rendering pages
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Minor
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-23 13:53 PDT by mod-wkbz
Modified: 2015-06-25 00:14 PDT (History)
6 users (show)

See Also:


Attachments
backtrace with symbols (7.53 KB, text/plain)
2015-06-23 13:53 PDT, mod-wkbz
no flags Details
Patch (1.43 KB, patch)
2015-06-23 23:29 PDT, Carlos Garcia Campos
svillar: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mod-wkbz 2015-06-23 13:53:15 PDT
Created attachment 255428 [details]
backtrace with symbols

On my Arch Linux x86_64 system, I don't have gconf/dconf/gnome-settings-daemon installed and have "gtk-font-name=" (with no value after the equals sign) under "[Settings]" in ~/.config/gtk-3.0/settings.ini. This configuration causes WebKit2's WebProcess to crash in WebCore::CSSParser::parseSystemFont with the attached backtrace, and prevents effectively all pages from being successfully rendered.

This occurs with both the packaged webkit2gtk 2.8.3-1 in the Arch repositories and with a freshly-built WebKit2GTK+ 2.8.3 from the same sources.

I debugged this in #webkitgtk+ IRC with mcatanzaro, who was able to reproduce by "[setting] org.gnome.desktop.font-name to an empty string with dconf-editor".
Comment 1 Michael Catanzaro 2015-06-23 13:58:33 PDT
It's actually org.gnome.desktop.interface font-name (oops). Check the See Also for a somewhat better backtrace

decltype(nullptr)&& is probably my new favorite C++ type.
Comment 2 Carlos Garcia Campos 2015-06-23 23:29:13 PDT
Created attachment 255473 [details]
Patch
Comment 3 Michael Catanzaro 2015-06-24 05:50:09 PDT
(I'd been using the STABLE tag for crashes that affect the latest stable release; how do you prefer we use those?)
Comment 4 Carlos Garcia Campos 2015-06-24 06:31:36 PDT
(In reply to comment #3)
> (I'd been using the STABLE tag for crashes that affect the latest stable
> release; how do you prefer we use those?)

I prefer is Stable is used for bugs that *only* affect stable releases. Bugs that are present in trunk and should be merged in stable branches, should be added to the stable wiki page to be merged in the branch once it lands in trunk.
Comment 5 Carlos Garcia Campos 2015-06-25 00:14:44 PDT
Committed r185948: <http://trac.webkit.org/changeset/185948>