Closed
Bug 868046
Opened 11 years ago
Closed 10 years ago
ABORT: should have bailed by now: 'nCsets > 0', file /home/work/B2G-unagi/birch/gfx/layers/ipc/ShadowLayers.cpp, line 403
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: dhylands, Assigned: milan)
References
Details
Attachments
(2 files)
215.48 KB,
text/plain
|
Details | |
1.14 KB,
patch
|
nical
:
review+
|
Details | Diff | Splinter Review |
I'm running a debug build on my unagi, using the master branch. If I launch an app like gallery, which supports different orientations, and start rotating the phone around, then after a few rotations (typically less than 10, although occaisonally it takes 40 or 50), I eventually get the following: ABORT: should have bailed by now: 'nCsets > 0', file /home/work/B2G-unagi/birch/gfx/layers/ipc/ShadowLayers.cpp, line 403
Reporter | ||
Comment 1•11 years ago
|
||
I don't see the problem with the Browser, but the browser doesn't run OOP. I see the problem with gallery and my test app (which is just a simple webapp), which both run OOP.
Comment 2•10 years ago
|
||
Still seeing this on 2.1 flame when starting cutTheRope Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080.1080] 0xb5b9a1c2 in mozalloc_abort ( msg=msg@entry=0xbe99a8dc "[Parent 1080] ###!!! ABORT: should have bailed by now: 'nCsets > 0 || mWindowOverlayChanged', file ../../../gfx/layers/ipc/ShadowLayers.cpp, line 623") at ../../../memory/mozalloc/mozalloc_abort.cpp:30 30 MOZ_CRASH(); (gdb) bt #0 0xb5b9a1c2 in mozalloc_abort ( msg=msg@entry=0xbe99a8dc "[Parent 1080] ###!!! ABORT: should have bailed by now: 'nCsets > 0 || mWindowOverlayChanged', file ../../../gfx/layers/ipc/ShadowLayers.cpp, line 623") at ../../../memory/mozalloc/mozalloc_abort.cpp:30 #1 0xb42ecfb0 in Abort ( aMsg=0xbe99a8dc "[Parent 1080] ###!!! ABORT: should have bailed by now: 'nCsets > 0 || mWindowOverlayChanged', file ../../../gfx/layers/ipc/ShadowLayers.cpp, line 623") at ../../../xpcom/base/nsDebugImpl.cpp:463 #2 NS_DebugBreak (aSeverity=<optimized out>, aStr=0xb5ea7363 "should have bailed by now", aExpr=0xb5ea737d "nCsets > 0 || mWindowOverlayChanged", aFile=0xb5ea706c "../../../gfx/layers/ipc/ShadowLayers.cpp", aLine=623) at ../../../xpcom/base/nsDebugImpl.cpp:450 #3 0xb4836cc0 in mozilla::layers::ShadowLayerForwarder::EndTransaction (this=0xaabdd460, aReplies=aReplies@entry=0xbe99c04c, aRegionToClear=..., aId=<error reading variable: Cannot access memory at address 0x1e>, aScheduleComposite=aScheduleComposite@entry=true, aPaintSequenceNumber=0, aIsRepeatTransaction=false, aTransactionStart=..., aSent=aSent@entry=0xbe99c033) at ../../../gfx/layers/ipc/ShadowLayers.cpp:623 #4 0xb480df12 in mozilla::layers::ClientLayerManager::ForwardTransaction (this=this@entry=0xaf805890, aScheduleComposite=aScheduleComposite@entry=true) at ../../../gfx/layers/client/ClientLayerManager.cpp:517 #5 0xb480e12c in EndEmptyTransaction (aFlags=mozilla::layers::LayerManager::END_NO_COMPOSITE, this=0xaf805890) at ../../../gfx/layers/client/ClientLayerManager.cpp:338 #6 mozilla::layers::ClientLayerManager::EndEmptyTransaction (this=0xaf805890, aFlags=mozilla::layers::LayerManager::END_NO_COMPOSITE) at ../../../gfx/layers/client/ClientLayerManager.cpp:322 #7 0xb51b69c8 in PresShell::Paint (this=0xb6a67100, aViewToPaint=0xaceb01f0, aDirtyRegion=..., aFlags=1) at ../../../layout/base/nsPresShell.cpp:6178 #8 0xb4e4fac8 in nsViewManager::ProcessPendingUpdatesPaint (this=0xace136d0, aWidget=aWidget@entry=0xac01ada0) at ../../view/nsViewManager.cpp:443 #9 0xb4e4fe18 in nsViewManager::ProcessPendingUpdatesForView (this=this@entry=0xac01ada0, aView=<optimized out>, aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at ../../view/nsViewManager.cpp:384 #10 0xb4e4fea8 in nsViewManager::ProcessPendingUpdates (this=this@entry=0xace136d0) at ../../view/nsViewManager.cpp:1075 #11 0xb4e4ff02 in nsViewManager::WillPaintWindow (this=0xace136d0, aWidget=aWidget@entry=0xac01ada0) at ../../view/nsViewManager.cpp:678 #12 0xb4e4d9a2 in nsView::WillPaintWindow (this=<optimized out>, aWidget=0xac01ada0) at ../../view/nsView.cpp:1040 #13 0xb4e74468 in nsWindow::DoDraw () at ../../../widget/gonk/nsWindow.cpp:196 #14 0xb4e7193a in nsAppShell::ProcessNextNativeEvent (this=0xb0fcbac0, mayWait=<optimized out>) at ../../../widget/gonk/nsAppShell.cpp:992 #15 0xb4e57790 in nsBaseAppShell::DoProcessNextNativeEvent (this=this@entry=0xb0fcbac0, mayWait=mayWait@entry=false, recursionDepth=recursionDepth@entry=0) at ../../../widget/xpwidgets/nsBaseAppShell.cpp:140 #16 0xb4e57844 in nsBaseAppShell::OnProcessNextEvent (this=0xb0fcbac0, thr=0xb6a4aaa0, mayWait=false, recursionDepth=0) at ../../../widget/xpwidgets/nsBaseAppShell.cpp:286 #17 0xb432c1bc in nsThread::ProcessNextEvent (this=0xb6a4aaa0, aMayWait=<optimized out>, aResult=0xbe99c5c7) at ../../../xpcom/threads/nsThread.cpp:794 #18 0xb433ee20 in NS_ProcessNextEvent (aThread=0xb6a4aaa0, aMayWait=aMayWait@entry=false) at ../../../xpcom/glue/nsThreadUtils.cpp:265
Flags: needinfo?(milan)
Updated•10 years ago
|
Component: General → Graphics: Layers
Product: Firefox OS → Core
Comment 3•10 years ago
|
||
Reproducible: 2/2
Assignee | ||
Comment 4•10 years ago
|
||
Sotaro, Nicolas, either one of you recognize this?
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(milan)
Comment 5•10 years ago
|
||
Looking at the hg history, I see that this assertion was introduced at this revision: http://hg.mozilla.org/mozilla-central/file/0de405102662/gfx/layers/ipc/ShadowLayers.cpp and was only about the number of edits in the transaction. The branch where I assume we should have bailed is here http://hg.mozilla.org/mozilla-central/file/0de405102662/gfx/layers/ipc/ShadowLayers.cpp#l301 and both the branch and the assertion are only about the number of edits. later the notion of screen rotation and overlay were added in the branch that early-returns, but only the overlay part is checked in the assertion. So the assertion could be wrong, and should maybe check whether the rotation changed too? I don't know if it makes sense to have a transaction with a rotation without a reflow to give you the appropriate content for the rotation, or if the two are not correlated.
Flags: needinfo?(nical.bugzilla)
I hit this too. The nested event loop is kind of interesting.
Blocks: 1038262
Comment 7•10 years ago
|
||
Still see it on master. Milan, what are the next steps here?
Flags: needinfo?(milan)
Assignee | ||
Comment 8•10 years ago
|
||
Other than being annoying, do you see any consequences of removing that assert? Just so that we know what the overall priority of this problem is.
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(milan)
Assignee | ||
Comment 9•10 years ago
|
||
I agree with Nicolas that the assert is likely wrong...
Attachment #8525352 -
Flags: review?(nical.bugzilla)
Assignee | ||
Updated•10 years ago
|
OS: Linux → Gonk (Firefox OS)
Updated•10 years ago
|
Attachment #8525352 -
Flags: review?(nical.bugzilla) → review+
Assignee | ||
Comment 10•10 years ago
|
||
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=69da8fef62dd
Comment 11•10 years ago
|
||
Thanks!
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → milan
Keywords: checkin-needed
Comment 12•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/42426a21f382
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/42426a21f382
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•