Closed Bug 623168 Opened 15 years ago Closed 4 years ago

Fennec crash [@ nsDisplayItem::RecomputeVisibility ]

Categories

(Core :: Web Painting, defect)

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

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
blocking2.0 --- -
fennec - ---

People

(Reporter: scoobidiver, Unassigned)

Details

(Keywords: crash, Whiteboard: [need-str][at-risk][mobile-crash])

Crash Data

It is #16 top crasher in Fennec 4.0b3 for the last week. Signature nsDisplayItem::RecomputeVisibility UUID 81f0a9df-b56b-4399-92be-8cabe2110104 Time 2011-01-04 14:18:07.332783 Uptime 0 Install Age 993003 seconds (1.6 weeks) since version was first installed. Product Fennec Version 4.0b3 Build ID 20101221205132 Branch 1.9 OS Linux OS Version 0.0.0 Linux 2.6.32.9 #1 Wed Nov 10 14:57:37 KST 2010 armv7l CPU arm Crash Reason SIGSEGV Crash Address 0x0 Frame Module Signature [Expand] Source 0 libxul.so nsDisplayItem::RecomputeVisibility layout/base/nsDisplayList.cpp:678 1 libxul.so mozilla::FrameLayerBuilder::DrawThebesLayer nsTArray.h:135 2 libxul.so mozilla::layers::BasicThebesLayer::PaintBuffer nsRegion.h:335 3 libxul.so mozilla::layers::BasicShadowableThebesLayer::PaintBuffer ShadowLayers.h:380 4 libxul.so mozilla::layers::BasicThebesLayer::Paint gfx/layers/basic/BasicLayers.cpp:538 5 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1311 6 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/Layers.h:599 7 libxul.so mozilla::layers::BasicLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:1230 8 libxul.so mozilla::layers::BasicShadowLayerManager::EndTransaction nsTArray.h:1189 9 libxul.so nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:478 10 libxul.so nsDisplayList::PaintRoot layout/base/nsDisplayList.cpp:385 11 libxul.so nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1443 12 libxul.so PresShell::Paint layout/base/nsPresShell.cpp:6095 13 libxul.so nsViewManager::RenderViews nsRegion.h:107 14 libxul.so nsViewManager::Refresh view/src/nsViewManager.h:250 15 libxul.so nsViewManager::DispatchEvent nsCOMPtr.h:492 16 libxul.so HandleEvent nsCOMPtr.h:492 17 libxul.so mozilla::widget::PuppetWidget::DispatchEvent widget/src/xpwidgets/PuppetWidget.cpp:306 18 libxul.so mozilla::widget::PuppetWidget::DispatchPaintEvent widget/src/xpwidgets/PuppetWidget.cpp:513 19 libxul.so mozilla::widget::PuppetWidget::PaintTask::Run widget/src/xpwidgets/PuppetWidget.cpp:555 20 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:626 21 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:250 22 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:111 23 libxul.so mozilla::ipc::MessagePumpForChildProcess::Run ipc/glue/MessagePump.cpp:230 24 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:220 25 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:512 26 libxul.so nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:198 27 libxul.so XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:631 28 libxul.so mozilla::ipc::MessagePumpForChildProcess::Run ipc/glue/MessagePump.cpp:222 29 libxul.so MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:220 30 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:512 31 libxul.so XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:510 32 libmozutils.so ChildProcessInit other-licenses/android/APKOpen.cpp:691 33 plugin-container main ipc/app/MozillaRuntimeMainAndroid.cpp:69 34 libc.so libc.so@0xd67a More reports at: http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nsDisplayItem%3A%3ARecomputeVisibility
tracking-fennec: --- → ?
blocking2.0: --- → ?
tracking-fennec: ? → 2.0+
Don't want to block without steps to reproduce
blocking2.0: ? → -
Assignee: nobody → azakai
It definitely shouldn't, not with that stack. Only nsDisplayClip can have a null underlying frame, and mozilla::FrameLayerBuilder::DrawThebesLayer shouldn't be drawing nsDisplayClips.
Hmm, other than that, I can only guess that mFrame is not null but is no longer valid. But it's very hard to tell without any way to reproduce.
Whiteboard: [need-str][at-risk]
tracking-fennec: 2.0+ → 2.0-
Without STR, nothing to do here.
Assignee: azakai → nobody
There have been no crashes in Fennec 4.0b5 so far, so I close it as "workforme".
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
We don't actually have any idea of what crashes are present in 4.0b5 at the moment until bug 637680 is resolved, just so you know. Virtually all existing 4.0b5 reports are meaningless.
It is #16 top crasher in 4.0.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
It is #10 top crasher in 4.0.1.
Crash Signature: [@ nsDisplayItem::RecomputeVisibility ]
Whiteboard: [need-str][at-risk] → [need-str][at-risk][mobile-crash]
Crash volume for signature 'nsDisplayItem::RecomputeVisibility': - nightly (version 50): 0 crash from 2016-06-06. - aurora (version 49): 2 crashes from 2016-06-07. - beta (version 48): 24 crashes from 2016-06-06. - release (version 47): 8 crashes from 2016-05-31. - esr (version 45): 0 crash from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 1 1 - beta 2 0 7 2 3 6 3 - release 2 0 1 2 0 1 1 - esr 0 0 0 0 0 0 0 Affected platform: Windows
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
Component: Layout → Layout: Web Painting

bug 1727774

Status: REOPENED → RESOLVED
Closed: 15 years ago → 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.