Firefox 4.0b Crash [@ _cairo_array_num_elements ]

RESOLVED FIXED

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: chris hofmann, Assigned: jfkthame)

Tracking

({crash, regression})

Trunk
x86
All
crash, regression
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
there is a crash on the trunk that looks like below.  

same signature exists on 3.6.3, but is much lower volume by about 13:1, and it might be another stack and bug

checking --- _cairo_array_num_elements 20100531-crashdata.csv
found in: 3.7a5pre 3.6.3
release total-crashes
              _cairo_array_num_elements crashes
                         pct.
all     372037  14      3.76307e-05
3.7a5pre        1716    13      0.00757576
3.6.3   259555  1       3.85275e-06

the 3.7a5pre stack looks like

http://crash-stats.mozilla.com/report/index/bb358d73-3ba3-4cdb-8e51-b1b082100601

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	_cairo_array_num_elements 	gfx/cairo/cairo/src/cairo-cache.c:48
1 	xul.dll 	gfxFont::Draw 	gfx/thebes/src/gfxFont.cpp:898
2 	xul.dll 	gfxTextRun::Draw 	gfx/thebes/src/gfxFont.cpp:2876
3 	xul.dll 	nsTextFrame::DrawText 	layout/generic/nsTextFrameThebes.cpp:4854
4 	xul.dll 	nsTextFrame::PaintText 	layout/generic/nsTextFrameThebes.cpp:4841
5 	xul.dll 	mozilla::FrameLayerBuilder::DrawThebesLayer 	layout/base/FrameLayerBuilder.cpp:532
6 	xul.dll 	mozilla::layers::BasicThebesLayer::Paint 	gfx/layers/basic/BasicLayers.cpp:266
7 	xul.dll 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:675
8 	xul.dll 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:678
9 	xul.dll 	mozilla::layers::BasicLayerManager::EndTransaction 	gfx/layers/basic/BasicLayers.cpp:569
10 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:464
11 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1262
12 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:5759
13 	xul.dll 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:426
14 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:877
15 	xul.dll 	HandleEvent 	view/src/nsView.cpp:160
16 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3220
17 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3248
18 	xul.dll 	nsWindow::OnPaint 	widget/src/windows/nsWindowGfx.cpp:535
19 	xul.dll 	nsWindow::ProcessMessage 	widget/src/windows/nsWindow.cpp:4239
20 	xul.dll 	nsWindow::WindowProc 	widget/src/windows/nsWindow.cpp:3955
21 	user32.dll 	InternalCallWinProc 	
22 	user32.dll 	UserCallWinProcCheckWow 	
23 	user32.dll 	DispatchClientMessage 	
24 	user32.dll 	__fnDWORD 	
25 	ntdll.dll 	KiUserCallbackDispatcher 	
26 	xul.dll 	xul.dll@0x5942f 	
27 	user32.dll 	DispatchMessageW 	
28 	xul.dll 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:294
29 	xul.dll 	nsTArray_base::ShiftData 	obj-firefox/xpcom/build/nsTArray.cpp:164
30 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:118
31 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:216
32 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:199
33 	xul.dll 	xul.dll@0x309613

more reports at http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=_cairo_array_num_elements&date=06%2F01%2F2010%2018%3A05%3A03&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=_cairo_array_num_elements
(Reporter)

Comment 1

8 years ago
probably the wrong component, but didn't see a better match.
blocking2.0: --- → ?
Keywords: crash
(Reporter)

Comment 2

8 years ago
yeah, here are the two stacks.  the 3.6.3 crash appears to run though font metrics code, and the trunk crash is running through nsTextFrame::DrawText and nsTextFrame::PaintText


  13 _cairo_array_num_elements
gfxFont::Draw(gfxTextRun *,unsigned int,unsigned int,gfxContext *,int,gfxPoint *,gfxFont::Spacing *)
gfxTextRun::Draw(gfxContext *,gfxPoint,unsigned int,unsigned int,gfxRect const *,gfxTextRun::PropertyProvider *,double *)
nsTextFrame::DrawText(gfxContext *,gfxPoint const &,unsigned int,unsigned int,gfxRect const *,PropertyProvider *,double &,int)
nsTextFrame::PaintText(nsIRenderingContext *,nsPoint,nsRect const &)
mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,void *)
mozilla::layers::BasicThebesLayer::Paint(gfxContext *,void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,void *),void *)

   1 _cairo_array_num_elements
gfxFont::Draw(gfxTextRun *,unsigned int,unsigned int,gfxContext *,int,gfxPoint *,gfxFont::Spacing *)
gfxTextRun::Draw(gfxContext *,gfxPoint,unsigned int,unsigned int,gfxRect const *,gfxTextRun::PropertyProvider *,double *)
nsThebesFontMetrics::DrawString(unsigned short const *,unsigned int,int,int,int,int const *,nsThebesRenderingContext *)
nsThebesRenderingContext::DrawString(unsigned short const *,unsigned int,int,int,int,int const *)
nsThebesRenderingContext::DrawString(nsString const &,int,int,int,int const *)
nsTextBoxFrame::DrawText(nsIRenderingContext &,nsRect const &,unsigned int const *)
(Reporter)

Comment 3

8 years ago
looks like the trunk form of the crash might have started showing up on may 17th, in builds from the 15th, with some spikes in the crashes around may 25 and yesterday.

date     crashes at
         cairo_array_num_elements
      count  release-builds
20100510 2 3.6.3-20100401080539
20100511 2 3.0.1-92010031422 3.6.3-20100401080539
20100512 1 3.6.3-20100401080539
20100513 1 3.6.3-20100401080539
20100514 5 3.6.3-20100401080539
20100515
20100516 2 3.6.3-20100401080539
20100517 2 3.7a5pre-20100515040001 3.5.9-20100315083431
20100518 7 3.5.9-20100315083431 3.6.3-20100401080539
20100519 5 3.5.9-20100315083431 3.6.320100401080539
20100520 5 3.7a5pre-20100519040042 3.6.320100401080539
20100521 2 3.7a5pre-20100519040042 3.6.320100401080539
20100522 11 3.7a5pre-20100522040023
20100523 11 3.7a5pre-20100522040023 3.7a5pre20100523040016 3.7a4webm-20100518233040
20100524
20100525 17 3.7a5pre-20100523042844 3.6.3-20100401080539
20100526 2 3.7a5pre-20100522040023 3.7a4webm-20100518233040
20100527 7 3.7a5pre-20100527040336 3.5.5-20091102152451
20100528 5 3.7a5pre-20100528040337 3.7a5pre-20100527040336
20100529 2 3.7a5pre-20100528040337 3.6.3-20100401080539
20100530 2 3.7a4webm-20100518233040
20100531 14 3.7a5pre-20100531040317 3.7a5pre-20100530040319 3.6.3-20100401080539

jst, if there is time to a fix for this into the next alpha/developer release we should try.
(Reporter)

Updated

8 years ago
Component: GFX: Color Management → Layout: Text
QA Contact: color-management → layout.fonts-and-text

Updated

8 years ago
Component: Layout: Text → Graphics
QA Contact: layout.fonts-and-text → thebes

Comment 4

8 years ago
so, this is a null pointer deref, but i can't figure out how to get a null pointer here (the stack trace is *probably* tail call optimized to oblivion)
Severity: normal → critical
blocking2.0: ? → -
(Reporter)

Comment 5

8 years ago
now running about 50-80 crashes per day with the increase in the beta test population, and ranked around #19 in non-plugin related crashes on 4.0 betas.
blocking2.0: - → ?
(Reporter)

Updated

8 years ago
Keywords: regression
Summary: Firefox 3.7a5pre Crash [@ _cairo_array_num_elements ] → Firefox 4.0b Crash [@ _cairo_array_num_elements ]
Assignee: nobody → jfkthame
blocking2.0: ? → final+
(Assignee)

Comment 6

8 years ago
Now that bug 553963 has landed, we should see whether this keeps happening in 4.0b3; it seems possible that the issues fixed there might have been leading to other null-deref crashes as well.
(Assignee)

Comment 7

8 years ago
(In reply to comment #6)
> we should see whether this keeps happening in
> 4.0b3

Errr..... beta4, I mean.
(Assignee)

Comment 8

8 years ago
Created attachment 469024 [details] [diff] [review]
patch, v1 - check for null mScaledFont before passing to cairo apis

So we're still seeing this crash signature in 4.0b4, though I don't know of any specific STR.

It looks like the crashes are occurring when gfxGDIFont::SetupCairoFont() calls cairo_scaled_font_status with a null mScaledFont.

This patch should prevent that crash by adding the appropriate null-checks, in case initialization of the cairo font failed for some reason.
Attachment #469024 - Flags: review?(jdaggett)

Updated

8 years ago
Attachment #469024 - Flags: review?(jdaggett) → review+
(Assignee)

Comment 9

8 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/94ac381a7893.

Leaving this bug open for now, waiting to see how crash-stats respond...
(Reporter)

Comment 10

8 years ago
yesterday we saw these numbers with about 310k users on beta4, and 250k on beta3

checking --- _cairo_array_num_elements 20100826-crashdata.csv
found in: 4.0b4 4.0b2 3.6.8
release total-crashes
              _cairo_array_num_elements crashes
                         pct.
all     291046  73      0.000250819
4.0b4   17931   65      0.00362501
4.0b2   1733    6       0.0034622
3.6.8   185994  2       1.0753e-05

check again on beta5
(Assignee)

Comment 11

8 years ago
Is this still happening? I couldn't seem to find any current reports on crash-stats, but the response to queries was being painfully slow and I may not have searched properly....
OS: Windows XP → All
(Reporter)

Comment 12

8 years ago
peaked out on sept 7 with 126 crashes.  now down to 8-12 crashes per day, but they are all b4 or older.

20101002 8  4 4.0b22010072019, 
	     3 4.0b42010081813, 1 3.6.82010072215, 
20101003 12  8 4.0b42010081813, 
	     3 4.0b22010072019, 1 3.6.32010040108,
(Reporter)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Crash Signature: [@ _cairo_array_num_elements ]
You need to log in before you can comment on or make changes to this bug.