Bug 61031 - [Qt] QtWebKit based browsers on Mac crash when displaying some pages with web fonts
Summary: [Qt] QtWebKit based browsers on Mac crash when displaying some pages with web...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.6
: P1 Major
Assignee: Nobody
Keywords: Qt, QtTriaged
Depends on:
Reported: 2011-05-18 02:32 PDT by igor.mikh
Modified: 2014-01-29 09:09 PST (History)
6 users (show)

See Also:

Logs for fancybrowser crash (30.39 KB, application/x-zip-compressed)
2011-05-18 02:33 PDT, igor.mikh
no flags Details
Qt 4.7.3 from MacPorts, WebKit r88132 builded from source (44.32 KB, text/plain)
2011-06-07 07:46 PDT, ndbizon
no flags Details
Qt 4.8.3, Mac OS X 10.8.2 (65.35 KB, text/plain)
2012-11-14 08:05 PST, Michał Łubiński
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description igor.mikh 2011-05-18 02:32:37 PDT
QtWebKit based Mac browsers (including Arora and fancybrowser sample shipped with Qt) may crash after the following steps are performed:

1. Open the page http://www.fontspring.com/ in the browser.
2. Press the Stop button while the page is being loaded (after at least one web font is loaded).
3. Open the page again.

Initially I reproduced this issue with a custom HTML page with web fonts. While searching for other pages that cause the crash I found that certain pages (sucha as http://www.google.com/webfonts) do not cause crash, while others (like Fontspring) do.

Crash logs from two different Macs are attached.

Environment details:
Qt: 4.7.3
QtWebKit: 2.0.2
WebKit: 533.3

Mac Configuration 1:
OS: Mac OS X 10.6.7
CPU: 1.66 GHz Intel Core Duo

Mac Configuration 2:
OS: Mac OS X 10.6.6
CPU: 2 GHz Intel Core 2 Duo
Comment 1 igor.mikh 2011-05-18 02:33:54 PDT
Created attachment 93889 [details]
Logs for fancybrowser crash
Comment 2 Benjamin Poulain 2011-05-18 04:59:57 PDT
(Note that we don't really support web fonts).
Raising to P1 since it is a crash. I haven't tried to reproduce yet.
Comment 3 igor.mikh 2011-05-20 07:09:28 PDT
This bug is not reproducible with Qt 4.6.0 (WebKit 532.1).
Comment 4 Alexis Menard (darktears) 2011-05-26 15:41:07 PDT
I can't reproduce with 4.7 branch fancy browser, neither QtWebKit 2.2 and QtWebKit trunk.

I believe I don't do the right step. Just open the page cancel when some fonts are loaded and reopen the page?
Comment 5 igor.mikh 2011-05-26 22:30:32 PDT
> Just open the page cancel when some fonts are loaded and reopen the page?

Yes, you are correct. I can also reproduce this issue using the following sequence. Please let me know if you see the same behavior.

1. Open the page http://www.fontspring.com/ in the Arora 0.11.0 (Qt 4.7.0) browser.
2. Wait until the page is loaded.
3. Reload the page.
4. Wait until the page is loaded.
5. Reload the page once more.
6. Arora quit unexpectedly.
Comment 6 ndbizon 2011-06-07 07:46:49 PDT
Created attachment 96243 [details]
Qt 4.7.3 from MacPorts, WebKit r88132 builded from source
Comment 7 ndbizon 2011-06-10 02:02:39 PDT
Right before the crash, the following lines is printed to the console terminal:
Fri Jun 10 11:58:27 Darkstar.local QtTestBrowser[37526] <Error>: ATSFontGetFileReference failed: error -50.
Bus error
Comment 8 Michał Łubiński 2012-11-14 08:05:24 PST
Created attachment 174160 [details]
Qt 4.8.3, Mac OS X 10.8.2

Reproduced with Qt 4.8.3 build from sources (QtWebKit 2.2.3) on my app on Mac OS X 10.8.2 (application was tested on Windows and Linux and worked well).

Here is thing that should interest devs.

Because of the size of QtWebKit sources I didn't have debug version of this framework. Instead of that I tried to find some hints what is wrong by simple fprintf's. ;) I checked 

    4   QtGui  0x0000000100b1fd07 QCoreTextFontEngine::QCoreTextFontEngine(__CTFont const*, QFontDef const&) + 273

and found out that the line which is related with the crash is:

    cgFont = CTFontCopyGraphicsFont(font, NULL);

Because there is no CTFontCopyGraphicsFont() call on the stacktrace I concluded that there is something wrong while performing operator=. But to be absolutely sure that CTFontCopyGraphicsFont works I made change in the code:

    CTFontCopyGraphicsFont(font, NULL);
    cgFont = CTFontCopyGraphicsFont(font, NULL);

For some reason it stopped crashing. Despite the fact that the function is from QtGui I'm pretty sure that the bug is related with @font-face and font cache. My app was crashing while processing font which was downloaded in a result of using font-face. Unfortunately I can't show any snippet of the code because this is commercial project, but I'll try to explain work of the app related with this bug. 

We have two webpages A and B. Webpage A has two tabs.

After rendering of webpage A, I can switch between tabs without rendering of complete webpage (e.g. when I'm switching to the second tab, images in the background are still on the screen, only part of the content is changing). At the first load of the page, fonts from font-face, printed to the console with toString() look like that:


When switching between tabs, fonts printed on console look like that:

    Some Font,-1,17,5,50,0,0,0,0,0

so they're already in local cache (?). I was able to switch between tabs of webpage A for as many times as I want without any crash. But after loading webpage B (which is also using same fonts) it crashes. Font info printed on console indicates that font is loaded locally:

    Some Font,-1,17,5,50,0,0,0,0,0
Comment 9 Ariya Hidayat 2012-12-29 21:40:33 PST
Probably interesting: http://code.google.com/p/phantomjs/issues/detail?id=690.
Comment 10 Matt Horan 2012-12-31 19:13:27 PST
This seems to be the source of crashes in the PhantomJS and capybara-webkit tools. In the case of capybara-webkit (and likely PhantomJS), triggering a "reset" of the browser, equivalent to a stop in the desktop browser, causes the crash. PhantomJS has implemented a workaround in a vendored copy of the Qt framework, however capybara-webkit links against system libraries.
Comment 11 Matt Horan 2013-01-02 10:30:27 PST
This issue is resolved in Qt 5 by http://trac.webkit.org/changeset/113968. However, this change has not been backported to a Qt 4.8 release. It'd be great to get a fix in Qt 4.8 given its prevalence.