Last Comment Bug 770263 - crash in _cairo_ft_font_face_scaled_font_create @ libxul.so@0xe... when opening links on http://www.golem.de/ticker/
: crash in _cairo_ft_font_face_scaled_font_create @ libxul.so@0xe... when openi...
Status: RESOLVED FIXED
[native-crash]
: crash, dogfood, regression, topcrash
Product: Core
Classification: Components
Component: Graphics: Text (show other bugs)
: 16 Branch
: ARM Android
: -- critical (vote)
: mozilla16
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 772168 (view as bug list)
Depends on:
Blocks: 769194
  Show dependency treegraph
 
Reported: 2012-07-02 11:09 PDT by Sebastian Hengst [:aryx][:archaeopteryx]
Modified: 2012-07-21 03:20 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
fixed
16+


Attachments

Description Sebastian Hengst [:aryx][:archaeopteryx] 2012-07-02 11:09:11 PDT
Fennec native nightly 2012-07-02 (but also seen with previous version, 2012-07-01 if I remember correct)
Android 4.0.4 (stock)
Google Nexus S

I got several times a crash [@ libxul.so@0xeb9144] and once [@ libxul.so@0xeb8a84] after visiting  http://www.golem.de/ticker/ and opening a linked story by tapping it long and choosing "Open in a new tab" from the context menu. Opening a new tab in the same way on a different page worked as expected.

https://crash-stats.mozilla.com/report/index/bp-b16eac9f-03fd-4943-8810-241e42120702
https://crash-stats.mozilla.com/report/index/bp-278c8589-b3f5-4e8a-b264-bc2442120702
https://crash-stats.mozilla.com/report/index/bp-a02916ba-6d7b-428d-8e88-302ea2120702
Comment 1 Scoobidiver (away) 2012-07-02 23:27:00 PDT
It's #1 top crasher on Nightly with about 45% of all crashes in the latest build.
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f08d285b63b0&tochange=d9d61d199b11

It's likely a regression from bug 539356 and might be a dupe of bug 770041.
Comment 2 Scoobidiver (away) 2012-07-04 10:47:32 PDT
aryx, does it still happen in the latest build (16.0a1/20120704) as bug 539356 has been backed out?
Comment 3 Sebastian Hengst [:aryx][:archaeopteryx] 2012-07-04 11:05:11 PDT
Yes, this still happens with Fennec native trunk nightly version 2012-07-04. Proof: https://crash-stats.mozilla.com/report/index/bp-ef6c357f-0162-4b39-9576-d08372120704
Comment 4 Scoobidiver (away) 2012-07-05 10:14:24 PDT
There are explicit stack traces in today's nightly:
Frame 	Module 	Signature 	Source
0 	libxul.so 	libxul.so@0xebc118 	
1 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x419dffe 	
2 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x419dffe 	
3 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x419dffe 	
4 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x453dffe 	
5 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x453dffe 	
6 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x419dffe 	
7 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x419dffe 	
8 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x453dffe 	
9 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x453dffe 	
10 	libxul.so 	_cairo_ft_font_face_scaled_font_create 	gfx/cairo/cairo/src/cairo-ft-font.c:1864
11 	libxul.so 	_moz_cairo_scaled_font_create 	gfx/cairo/cairo/src/cairo-scaled-font.c:1053
12 	libxul.so 	FT2FontEntry::CreateScaledFont 	gfx/thebes/gfxFT2FontList.cpp:127
13 	libxul.so 	FT2FontEntry::CreateFontInstance 	gfx/thebes/gfxFT2FontList.cpp:152
14 	libxul.so 	gfxFontEntry::FindOrMakeFont 	gfx/thebes/gfxFont.cpp:187
15 	libxul.so 	gfxFontGroup::FindPlatformFont 	gfx/thebes/gfxFont.cpp:3050
16 	libxul.so 	gfxFontGroup::FontResolverProc 	gfx/thebes/gfxFont.cpp:3296
17 	libxul.so 	gfxFontGroup::ForEachFontInternal 	gfx/thebes/gfxFont.cpp:3251
18 	libxul.so 	gfxFontGroup::ForEachFont 	gfx/thebes/gfxFont.cpp:3108
19 	libxul.so 	gfxFontGroup::BuildFontList 	gfx/thebes/gfxFont.cpp:2946
20 	libxul.so 	gfxFontGroup::gfxFontGroup 	gfx/thebes/gfxFont.cpp:2937
21 	libxul.so 	gfxAndroidPlatform::CreateFontGroup 	gfx/thebes/gfxAndroidPlatform.cpp:145
22 	libxul.so 	nsFontMetrics::Init 	gfx/src/nsFontMetrics.cpp:109
23 	libxul.so 	nsFontCache::GetMetricsFor 	gfx/src/nsDeviceContext.cpp:139
24 	libxul.so 	nsDeviceContext::GetMetricsFor 	gfx/src/nsDeviceContext.cpp:254
25 	libxul.so 	nsLayoutUtils::GetFontMetricsForStyleContext 	layout/base/nsLayoutUtils.cpp:2084
26 	libxul.so 	nsLayoutUtils::GetFontMetricsForFrame 	layout/base/nsLayoutUtils.cpp:2064
27 	libxul.so 	GetFontGroupForFrame 	layout/generic/nsTextFrameThebes.cpp:1617
28 	libxul.so 	BuildTextRunsScanner::BuildTextRunForFrames 	layout/generic/nsTextFrameThebes.cpp:1873
...

I think it's a regression from bug 769194.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xebc118+|+_cairo_ft_font_face_scaled_font_create
Comment 5 Jonathan Kew (:jfkthame) 2012-07-05 11:55:14 PDT
Yes, almost certainly a regression from bug 769194; the  http://www.golem.de  pages are using CSS (from Google webfonts) that loads the Droid fonts using src:local() if available. I'll try to reproduce locally; but if we can't fix this quickly, we could temporarily back out 769194 to avoid the issue.
Comment 6 Scoobidiver (away) 2012-07-07 00:27:35 PDT
It still accounts for about 30% of all crashes.
Comment 7 Jonathan Kew (:jfkthame) 2012-07-09 03:33:39 PDT
In my testing, it seems like this occurs if a page uses @font-face with src:local() to load a font that has *not* already been used directly via css font-family. So the http://www.golem.de/ticker/ article pages tend to hit it because they use Droid Serif via src:local(), but the browser's default is sans-serif and so it's quite likely that Droid Serif, or at least some of its faces, has not previously been used.

The crashes tend to be close to startup, as the longer the browser has been running, the more likely it is that the fonts will have been used "normally" through font-family already, in which case the src:local() usage no longer crashes, AFAICT.
Comment 8 Daniel Holbert [:dholbert] 2012-07-09 13:01:56 PDT
*** Bug 772168 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Holbert [:dholbert] 2012-07-09 13:04:41 PDT
Note that (per bug 772168 comment 2) this appears to make us crash at browserid.org, and hence prevents Nightly users from logging into any browserid-dependent site.

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> but if we can't fix
> this quickly, we could temporarily back out 769194 to avoid the issue.

Perhaps a backout is in order, given the crash volume and the browserid bustage?
Comment 10 Jonathan Kew (:jfkthame) 2012-07-09 14:50:26 PDT
I just backed out bug 769194 on inbound, so I'm expecting these crashes to stop happening once that goes out in nightlies.
Comment 11 Jonathan Kew (:jfkthame) 2012-07-18 19:53:43 PDT
AFAICT from crash-stats, this no longer occurs since the backout of 769194, so we can resolve it as FIXED; archaeopteryx, scoobidiver, would you agree?
Comment 12 Scoobidiver (away) 2012-07-19 01:01:10 PDT
(In reply to Jonathan Kew (:jfkthame) from comment #11)
> AFAICT from crash-stats, this no longer occurs since the backout of 769194,
> so we can resolve it as FIXED; archaeopteryx, scoobidiver, would you agree?
That's right.
Comment 13 Sebastian Hengst [:aryx][:archaeopteryx] 2012-07-21 03:20:29 PDT
It's fixed for me in Fennec trunk nightly 2012-07-20.

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