Closed Bug 681114 Opened 14 years ago Closed 13 years ago

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

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 756253
Tracking Flags:
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: nhirata, Assigned: BenWa)

Details

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

Crash Data

Attachments

(3 files)

Diagnostic
5.84 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
Log from droid razr on kijiji.ca
11.95 KB, text/plain
Details
Diagnostic 2
5.44 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
This bug was filed from the Socorro interface and is report bp-2e72aded-e4b5-4bad-a829-af02d2110822 . ============================================================= Frame Module Signature [Expand] Source 0 libxul.so _cairo_user_data_array_fini gfx/cairo/cairo/src/cairo-array.c:389 1 libxul.so _moz_cairo_surface_destroy gfx/cairo/cairo/src/cairo-surface.c:655 2 libxul.so gfxASurface::Release gfx/thebes/gfxASurface.cpp:127 3 libxul.so imgFrame::~imgFrame nsAutoPtr.h:968 4 libxul.so mozilla::imagelib::RasterImage::Discard mozalloc.h:253 5 libxul.so mozilla::imagelib::DiscardTracker::TimerCallback modules/libpr0n/src/DiscardTracker.cpp:267 6 libxul.so nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 7 libxul.so nsTimerEvent::Run nsAutoPtr.h:969 8 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:631 9 libxul.so NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:245 10 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:111 11 libxul.so mozilla::ipc::MessagePumpForChildProcess::Run ipc/glue/MessagePump.cpp:230 12 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:222 13 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:514 14 libxul.so nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:191 15 libxul.so XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:673 16 libxul.so mozilla::ipc::MessagePumpForChildProcess::Run ipc/glue/MessagePump.cpp:222 17 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:222 18 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:514 19 libxul.so XRE_InitChildProcess nsAutoPtr.h:155 20 libmozutils.so ChildProcessInit other-licenses/android/APKOpen.cpp:796 21 plugin-container main ipc/app/MozillaRuntimeMainAndroid.cpp:69 22 libc.so libc.so@0xd43a More signature reports: https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-08-22%2013%3A00%3A00&signature=_cairo_user_data_array_fini&version=Fennec%3A9.0a1 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 libxul.so _cairo_user_data_array_fini gfx/cairo/cairo/src/cairo-array.c:389 1 libxul.so _moz_cairo_surface_destroy gfx/cairo/cairo/src/cairo-surface.c:654 2 libxul.so gfxASurface::Release gfx/thebes/gfxASurface.cpp:120 3 libxul.so gfxReusableSurfaceWrapper::~gfxReusableSurfaceWrapper nsAutoPtr.h:908 4 libxul.so gfxReusableSurfaceWrapper::Release gfxReusableSurfaceWrapper.h:31 5 libxul.so mozilla::layers::TiledLayerBuffer<mozilla::layers::BasicTiledLayerBuffer, mozill nsAutoPtr.h:908 6 libxul.so mozilla::layers::BasicTiledLayerBuffer::PaintThebes gfx/layers/basic/BasicTiledThebesLayer.cpp:117 7 libxul.so mozilla::layers::BasicTiledThebesLayer::PaintThebes gfx/layers/basic/BasicTiledThebesLayer.cpp:235 8 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1875 9 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1890 10 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1890 11 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1890 12 libxul.so mozilla::layers::BasicLayerManager::EndTransactionInternal gfx/layers/basic/BasicLayers.cpp:1580 13 libxul.so mozilla::layers::BasicShadowLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:1527 14 libxul.so nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:651 15 libxul.so nsDisplayList::PaintRoot layout/base/nsDisplayList.cpp:556 16 libxul.so 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 https://crash-stats.mozilla.com/report/list?signature=_cairo_user_data_array_fini&product=FennecAndroid
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 Diagnostic — — Splinter Review
Running this through try: https://tbpl.mozilla.org/?tree=Try&rev=09280d908118
Assignee: jmuizelaar → bgirard
Status: NEW → ASSIGNED
Attachment #625264 - Flags: review?(jmuizelaar)
Comment on attachment 625264 [details] [diff] [review] Diagnostic 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: http://mxr.mozilla.org/mozilla-central/source/memory/mozalloc/mozalloc_abort.cpp#64
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: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-c4a0c6833b09/try-android-debug/
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. 724035e9-c48c-4174-b475-1cb472120521
https://crash-stats.mozilla.com/report/index/724035e9-c48c-4174-b475-1cb472120521 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?
Correct.
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: libxul.so exists but is not directory unable to process libxul.so/ADCE37F3748C53682A7A3E874EE68C820/libxul.so.sym. 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. https://hg.mozilla.org/integration/mozilla-inbound/rev/3d38f4633f50
Diagnostic: https://hg.mozilla.org/mozilla-central/rev/3d38f4633f50 (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 2 — — Splinter 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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/332846907076 Waiting on this is merged to central before requesting more help.
Keywords: qawanted
Merged to m-c: https://hg.mozilla.org/mozilla-central/rev/332846907076 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.
Status: ASSIGNED → RESOLVED
Closed: 13 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.

Attachment

General

Creator:
Created:
Updated:
Size: