Bug 61031 - [Qt] QtWebKit based browsers on Mac crash when displaying some pages with web fonts
: [Qt] QtWebKit based browsers on Mac crash when displaying some pages with web...
: WebKit
Layout and Rendering
: 528+ (Nightly build)
: Macintosh Intel Mac OS X 10.6
: P1 Major
Assigned To:
: Qt, QtTriaged
  Show dependency treegraph
Reported: 2011-05-18 02:32 PST by
Modified: 2014-01-29 09:09 PST (History)

Logs for fancybrowser crash (30.39 KB, application/x-zip-compressed)
2011-05-18 02:33 PST, igor.mikh@gmail.com
no flags Details
Qt 4.7.3 from MacPorts, WebKit r88132 builded from source (44.32 KB, text/plain)
2011-06-07 07:46 PST, ndbizon@gmail.com
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


You need to log in before you can comment on or make changes to this bug.

Description From 2011-05-18 02:32:37 PST
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 From 2011-05-18 02:33:54 PST -------
Created an attachment (id=93889) [details]
Logs for fancybrowser crash
------- Comment #2 From 2011-05-18 04:59:57 PST -------
(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 From 2011-05-20 07:09:28 PST -------
This bug is not reproducible with Qt 4.6.0 (WebKit 532.1).
------- Comment #4 From 2011-05-26 15:41:07 PST -------
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 From 2011-05-26 22:30:32 PST -------
> 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 From 2011-06-07 07:46:49 PST -------
Created an attachment (id=96243) [details]
Qt 4.7.3 from MacPorts, WebKit r88132 builded from source
------- Comment #7 From 2011-06-10 02:02:39 PST -------
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 From 2012-11-14 08:05:24 PST -------
Created an attachment (id=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 From 2012-12-29 21:40:33 PST -------
Probably interesting: http://code.google.com/p/phantomjs/issues/detail?id=690.
------- Comment #10 From 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 From 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.