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)

x86_64
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: dhylands, Assigned: milan)

References

Details

Attachments

(2 files)

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
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.
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)
Component: General → Graphics: Layers
Product: Firefox OS → Core
Reproducible: 2/2
Sotaro, Nicolas, either one of you recognize this?
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(milan)
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)
Attached file Crash report
I hit this too.  The nested event loop is kind of interesting.
Still see it on master. Milan, what are the next steps here?
Flags: needinfo?(milan)
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)
Attached patch Fix the assert.Splinter Review
I agree with Nicolas that the assert is likely wrong...
Attachment #8525352 - Flags: review?(nical.bugzilla)
OS: Linux → Gonk (Firefox OS)
Attachment #8525352 - Flags: review?(nical.bugzilla) → review+
Thanks!
Assignee: nobody → milan
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.