Closed Bug 681114 Opened 13 years ago Closed 12 years ago

crash in mozilla::layers::BasicTiledLayerBuffer::PaintThebes @ _cairo_user_data_array_fini


(Core :: Graphics, defect)

Not set



Tracking Status
blocking-fennec1.0 --- -


(Reporter: nhirata, Assigned: BenWa)


(Keywords: crash, topcrash, Whiteboard: [native-crash][leave open][gfx])

Crash Data


(3 files)

This bug was filed from the Socorro interface and is 
report bp-2e72aded-e4b5-4bad-a829-af02d2110822 .

Frame 	Module 	Signature [Expand] 	Source
0 	_cairo_user_data_array_fini 	gfx/cairo/cairo/src/cairo-array.c:389
1 	_moz_cairo_surface_destroy 	gfx/cairo/cairo/src/cairo-surface.c:655
2 	gfxASurface::Release 	gfx/thebes/gfxASurface.cpp:127
3 	imgFrame::~imgFrame 	nsAutoPtr.h:968
4 	mozilla::imagelib::RasterImage::Discard 	mozalloc.h:253
5 	mozilla::imagelib::DiscardTracker::TimerCallback 	modules/libpr0n/src/DiscardTracker.cpp:267
6 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:425
7 	nsTimerEvent::Run 	nsAutoPtr.h:969
8 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:631
9 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
10 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:111
11 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:230
12 	MessageLoop::RunInternal 	ipc/chromium/src/base/
13 	MessageLoop::Run 	ipc/chromium/src/base/
14 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:191
15 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp:673
16 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:222
17 	MessageLoop::RunInternal 	ipc/chromium/src/base/
18 	MessageLoop::Run 	ipc/chromium/src/base/
19 	XRE_InitChildProcess 	nsAutoPtr.h:155
20 	ChildProcessInit 	other-licenses/android/APKOpen.cpp:796
21 	plugin-container 	main 	ipc/app/MozillaRuntimeMainAndroid.cpp:69

More signature reports:

Related to bug 612096?
Component: GFX: Color Management → Graphics
QA Contact: color-management → thebes
Keywords: crash, topcrash
Whiteboard: [mobile-crash]
Assignee: nobody → jmuizelaar
Keywords: topcrash
Dupe of bug 715097?
With bug 715097, it's #12 top crasher in the first days of 14.0b1.

The first frames of the stack now look like:
Frame 	Module 	Signature 	Source
0 	_cairo_user_data_array_fini 	gfx/cairo/cairo/src/cairo-array.c:389
1 	_moz_cairo_surface_destroy 	gfx/cairo/cairo/src/cairo-surface.c:654
2 	gfxASurface::Release 	gfx/thebes/gfxASurface.cpp:120
3 	gfxReusableSurfaceWrapper::~gfxReusableSurfaceWrapper 	nsAutoPtr.h:908
4 	gfxReusableSurfaceWrapper::Release 	gfxReusableSurfaceWrapper.h:31
5 	mozilla::layers::TiledLayerBuffer<mozilla::layers::BasicTiledLayerBuffer, mozill 	nsAutoPtr.h:908
6 	mozilla::layers::BasicTiledLayerBuffer::PaintThebes 	gfx/layers/basic/BasicTiledThebesLayer.cpp:117
7 	mozilla::layers::BasicTiledThebesLayer::PaintThebes 	gfx/layers/basic/BasicTiledThebesLayer.cpp:235
8 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1875
9 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1890
10 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1890
11 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1890
12 	mozilla::layers::BasicLayerManager::EndTransactionInternal 	gfx/layers/basic/BasicLayers.cpp:1580
13 	mozilla::layers::BasicShadowLayerManager::EndTransaction 	gfx/layers/basic/BasicLayers.cpp:1527
14 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:651
15 	nsDisplayList::PaintRoot 	layout/base/nsDisplayList.cpp:556
16 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1802
Summary: crash [@ _cairo_user_data_array_fini] → crash in mozilla::layers::BasicTiledLayerBuffer::PaintThebes @ _cairo_user_data_array_fini
Whiteboard: [mobile-crash] → [native-crash]
I can't reproduce this crash using the steps in bug 756253 and all the crash are with the same build ID.
Depends on: 756253
(In reply to Benoit Girard (:BenWa) from comment #3)
> all the crash are with the same build ID.
No. See
Ok thanks, taking another look.
I look at the gfx/cairo/cairo/src/cairo-array.c carefully and the crash is caused by the array object entering a bad state and crashing on release. Since the bug doesn't reproduce Jeff and I decided that we should land runtime assertion that will cause the crash to happen sooner. This will transform this crash into a more useful report.
Depends on: 756556
No longer depends on: 756556
Attached patch DiagnosticSplinter Review
Running this through try:
Assignee: jmuizelaar → bgirard
Attachment #625264 - Flags: review?(jmuizelaar)
Comment on attachment 625264 [details] [diff] [review]

This is fine, provided abort() does the right thing. If you're not sure you can easily just cobble together a function that will crash.
Attachment #625264 - Flags: review?(jmuizelaar) → review+
abort will end up calling mozalloc_abort then TouchBadMemory:
No longer depends on: 756253
BMO bug relationship appear to be broken today.
Depends on: 756253
Would this also fix bug 746730?
It's #7 top crasher in 14.0b2.
blocking-fennec1.0: --- → ?
Keywords: topcrash
mobile triage: Do we have STR for this? leaving nom pending further information
Keywords: qawanted
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #12)
> Would this also fix bug 746730?

I don't believe they are related.
(In reply to :Ally Naaktgeboren from comment #14)
> mobile triage: Do we have STR for this? leaving nom pending further
> information
STR are in bug 756253.
I tried the STR in bug 756253 but with no luck. If someone can reproduce using those steps it would be helpful to try with the diagnostic build and give me the crash ID:
The log has a minidump ID of 155d7a3a-8182-72fc-2621989b-03b43e25 but I can't get the crash report from it. How do I translate it?
Crash ids and processed crash ids are two different numbers. You can tell a processed crash id from and unprocessed id by checking the ending digits. If they look like a date 120521 then it is processed. 


Looks like I'll need to symbolicate it by hand. I'll take a look tomorrow.

Kevin, just to confirm were you running the build from comment 17?
blocking-fennec1.0: ? → +
BenWa, you should be able to get the proper crash report, by clicking on the link, then refreshing the about:crashes.

Ted, is that bug 622555?
Naoki the crash was on my device, so that would not work.
Sorry, is what what bug?

BenWa: if you're crashing a try build, crash-stats doesn't have symbols for it, so it can't give you a good stack.
I can't extract the symbols folder manually :(

checkdir error: exists but is not directory
                 unable to process

Is there anything I can do to get a good stack out of this? If not I'll just land the diagnostic patch on central and back it out once we have the data.
Landed for now. I'll back it out once we have enough data.

(I happened to notice comment 27 by chance; if you'd like a bug left open, the best way is to add [leave open] to the whiteboard - particularly once the bug marking is scripted)
Whiteboard: [native-crash] → [native-crash][leave open]
Whiteboard: [native-crash][leave open] → [native-crash][leave open][gfx]
qawanted: kevin to take a look on droid razr, latest build
Excellent, be sure to include the crash id
Interesting. Some crash have different signature (unrelated maybe?). Some of these crash crashes in _cairo_user_data_array_fini. Thanks Kevin!
They were all from the same action on the page pinch zooming.
Attached patch Diagnostic 2Splinter Review
Going to wait on try results before landing.
Attachment #627377 - Flags: review?(jmuizelaar)
Comment on attachment 627377 [details] [diff] [review]
Diagnostic 2

Review of attachment 627377 [details] [diff] [review]:

Lets try again.
Attachment #627377 - Flags: review?(jmuizelaar) → review+

Waiting on this is merged to central before requesting more help.
Keywords: qawanted
Merged to m-c:

Nightlies retriggered on m-c tip (78852a6d11ab).
I'm still treating this as a tentative dupe of bug 756253. You can see the progress there.
We're relying on bug 756253 as the mobile blocker. This, being an older and possibly not mobile-specific bug, gets to fall off the blocker list.
blocking-fennec1.0: + → -
Let's mark it as a dupe of bug 756253.
Closed: 12 years ago
No longer depends on: 756253
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.