Bug 146246

Summary: [GTK] Empty gtk-font-name setting causes WebProcess crash rendering pages
Product: WebKit Reporter: mod-wkbz
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Minor CC: cgarcia, commit-queue, esprehn+autocc, glenn, kondapallykalyan, mcatanzaro
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1235045
Attachments:
Description Flags
backtrace with symbols
none
Patch svillar: review+

mod-wkbz
Reported 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".
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+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 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.
Carlos Garcia Campos
Comment 2 2015-06-23 23:29:13 PDT
Created attachment 255473 [details] Patch
Michael Catanzaro
Comment 3 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?)
Carlos Garcia Campos
Comment 4 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.
Carlos Garcia Campos
Comment 5 2015-06-25 00:14:44 PDT
Committed r185948: <http://trac.webkit.org/changeset/185948>
Note You need to log in before you can comment on or make changes to this bug.