1103106 - Assertion failure: !mWillChangeBudgetCalculated (Can't modify the budget once it's been used.), at ../../../layout/base/nsDisplayList.cpp:1231

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Gregor Wagner [:gwagner]]

On current b2g trunk on flame
STR: Open settigs app and try to open sub panel.

Comment 1

[Gregor Wagner [:gwagner]]

Build ID for b-i
changeset:   216873:3390381e5499
tag:         tip
user:        B2G Bumper Bot <[e-mail]>
date:        Fri Nov 21 11:07:17 2014 -0800
summary:     Bumping manifests a=b2g-bump

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Recent regression?

Comment 3

[Gregor Wagner [:gwagner]]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Recent regression?

I think yes. I tested a debug build a week ago but I can't guarantee that I entered a sub-panel in settings back then.

Comment 4

[Benoit Girard (:BenWa)]

It could be a regression from a change somewhere else in layout. I had to refactor and make sure that we accounted all will-change elements because we started checking if they would be use.

Ideally we should perform a regression windows. Otherwise getting a stacktrace would be handy to see what is asking for the will-change budget early. We'd need to also have the stacktrace for the thing that modified mWillChangeBudgetCalculated before the assertion is hit.

Comment 5

[Gregor Wagner [:gwagner]]

Thats a bt from the settings app:
Program received signal SIGSEGV, Segmentation fault.
0xb55c82e6 in nsDisplayListBuilder::AddToWillChangeBudget (this=this@entry=0xbec124b8, aFrame=aFrame@entry=0xb10a9190, aRect=...) at ../../../layout/base/nsDisplayList.cpp:1230
1230	  MOZ_ASSERT(!mWillChangeBudgetCalculated,
(gdb) bt
#0  0xb55c82e6 in nsDisplayListBuilder::AddToWillChangeBudget (this=this@entry=0xbec124b8, aFrame=aFrame@entry=0xb10a9190, aRect=...) at ../../../layout/base/nsDisplayList.cpp:1230
#1  0xb5644e8c in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb10a91e0, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:2937
#2  0xb564394e in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb10a52e0, aBuilder=aBuilder@entry=0xbec124b8, aChild=aChild@entry=0xb10ab5a0, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=4)
    at ../../../layout/generic/nsFrame.cpp:2436
#3  0xb561c9d2 in DisplayLine (aBuilder=aBuilder@entry=0xbec124b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbec102b8: -1094646960, aLists=..., aFrame=aFrame@entry=0xb10a52e0, 
    aTextOverflow=0x0) at ../../../layout/generic/nsBlockFrame.cpp:6244
#4  0xb562865e in nsBlockFrame::BuildDisplayList (this=0xb10a52e0, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#5  0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=0xb10a4fe0, aBuilder=aBuilder@entry=0xbec124b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2417
#6  0xb5644ff4 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb10a5030, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:3017
#7  0xb5642e56 in nsIFrame::BuildDisplayListForStackingContext (this=this@entry=0xb10a4fe0, aBuilder=aBuilder@entry=0xbec124b8, aDirtyRect=..., aList=aList@entry=0xbec10b28) at ../../../layout/generic/nsFrame.cpp:2036
#8  0xb564382c in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb09c0d40, aBuilder=aBuilder@entry=0xbec124b8, aChild=aChild@entry=0xb10a5340, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=4)
    at ../../../layout/generic/nsFrame.cpp:2382
#9  0xb561c9d2 in DisplayLine (aBuilder=aBuilder@entry=0xbec124b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbec10e28: 0, aLists=..., aFrame=aFrame@entry=0xb09c0d40, aTextOverflow=0x0)
    at ../../../layout/generic/nsBlockFrame.cpp:6244
#10 0xb562865e in nsBlockFrame::BuildDisplayList (this=0xb09c0d40, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#11 0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=0xb09c0a78, aBuilder=aBuilder@entry=0xbec124b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2417
#12 0xb5644ff4 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb09c0ac8, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:3017
#13 0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb09c0288, aBuilder=aBuilder@entry=0xbec124b8, aChild=aChild@entry=0xb09c0a78, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0)
    at ../../../layout/generic/nsFrame.cpp:2417
#14 0xb561c9d2 in DisplayLine (aBuilder=aBuilder@entry=0xbec124b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbec11780: -1295829664, aLists=..., aFrame=aFrame@entry=0xb09c0288, 
    aTextOverflow=0x0) at ../../../layout/generic/nsBlockFrame.cpp:6244
#15 0xb562865e in nsBlockFrame::BuildDisplayList (this=0xb09c0288, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#16 0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1062800, aBuilder=aBuilder@entry=0xbec124b8, aChild=aChild@entry=0xb09c0288, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0)
    at ../../../layout/generic/nsFrame.cpp:2417
#17 0xb561a25e in nsCanvasFrame::BuildDisplayList (this=0xb1062800, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsCanvasFrame.cpp:461
#18 0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=0xb1062a00, aBuilder=aBuilder@entry=0xbec124b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2417
#19 0xb5644d20 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb1062a50, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:2855
#20 0xb56438f0 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb10622b8, aBuilder=aBuilder@entry=0xbec124b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0)
    at ../../../layout/generic/nsFrame.cpp:2417
#21 0xb566fff6 in ViewportFrame::BuildDisplayList (this=0xb10622b8, aBuilder=0xbec124b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsViewportFrame.cpp:61
#22 0xb5642e56 in nsIFrame::BuildDisplayListForStackingContext (this=this@entry=0xb10622b8, aBuilder=aBuilder@entry=0xbec124b8, aDirtyRect=..., aList=aList@entry=0xbec1246c) at ../../../layout/generic/nsFrame.cpp:2036
#23 0xb55ed00a in nsLayoutUtils::PaintFrame (aRenderingContext=aRenderingContext@entry=0x0, aFrame=aFrame@entry=0xb10622b8, aDirtyRegion=..., aBackstop=aBackstop@entry=0, aFlags=772) at ../../../layout/base/nsLayoutUtils.cpp:2972
#24 0xb55faf1e in PresShell::Paint (this=0xb2cac3e0, aViewToPaint=0xb1009650, aDirtyRegion=..., aFlags=1) at ../../../layout/base/nsPresShell.cpp:6337
#25 0xb546cf08 in nsViewManager::ProcessPendingUpdatesPaint (this=0xb10291f0, aWidget=aWidget@entry=0xb17a0f00) at ../../view/nsViewManager.cpp:443
#26 0xb546d258 in nsViewManager::ProcessPendingUpdatesForView (this=this@entry=0xb2ccf260, aView=<optimized out>, aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at ../../view/nsViewManager.cpp:384
#27 0xb546d2e6 in nsViewManager::ProcessPendingUpdates (this=this@entry=0xb10291f0) at ../../view/nsViewManager.cpp:1075
#28 0xb55940a2 in nsRefreshDriver::Tick (this=0xb2ccf260, this@entry=0xb1165dc0, aNowEpoch=<optimized out>, aNowTime=...) at ../../../layout/base/nsRefreshDriver.cpp:1358
#29 0xb55946c6 in mozilla::RefreshDriverTimer::TickDriver (driver=0xb1165dc0, jsnow=<optimized out>, now=..., now@entry=...) at ../../../layout/base/nsRefreshDriver.cpp:175
#30 0xb55947e4 in mozilla::RefreshDriverTimer::Tick (this=0xb1165dc0) at ../../../layout/base/nsRefreshDriver.cpp:166
#31 0xb46a7122 in nsTimerImpl::Fire (this=0xb1176fb0) at ../../../xpcom/threads/nsTimerImpl.cpp:621
#32 0xb46a72a6 in nsTimerEvent::Run (this=0xb117f130) at ../../../xpcom/threads/nsTimerImpl.cpp:714
#33 0xb46a4af8 in nsThread::ProcessNextEvent (this=0xb384c230, aMayWait=<optimized out>, aResult=0xbec12c97) at ../../../xpcom/threads/nsThread.cpp:830
#34 0xb46b9164 in NS_ProcessNextEvent (aThread=0xb384c230, aMayWait=aMayWait@entry=false) at /Volumes/2mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:265
#35 0xb486e17c in mozilla::ipc::MessagePump::Run (this=0xb3801df0, aDelegate=0xbec12df0) at ../../../ipc/glue/MessagePump.cpp:99
#36 0xb485a0e4 in MessageLoop::RunInternal (this=this@entry=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:233
---Type <return> to continue, or q <return> to quit---
#37 0xb485a0fe in RunHandler (this=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#38 MessageLoop::Run (this=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#39 0xb54704a2 in nsBaseAppShell::Run (this=0xb2c68460) at ../../widget/nsBaseAppShell.cpp:164
#40 0xb58b6bba in XRE_RunAppShell () at ../../../toolkit/xre/nsEmbedFunctions.cpp:731
#41 0xb486e2aa in mozilla::ipc::MessagePumpForChildProcess::Run (this=0xb3801df0, aDelegate=0xbec12df0) at ../../../ipc/glue/MessagePump.cpp:272
#42 0xb485a0e4 in MessageLoop::RunInternal (this=this@entry=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:233
#43 0xb485a0fe in RunHandler (this=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#44 MessageLoop::Run (this=this@entry=0xbec12df0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#45 0xb58b6b1a in XRE_InitChildProcess (aArgc=<optimized out>, aArgv=<optimized out>, aGMPLoader=<optimized out>) at ../../../toolkit/xre/nsEmbedFunctions.cpp:568
#46 0x000092a8 in content_process_main (argc=6, argv=0xbec138e4) at ../../../ipc/app/../contentproc/plugin-container.cpp:190
#47 0xb6e4a4a4 in __libc_init (raw_args=0xbec138e0, onexit=<optimized out>, slingshot=0x9309 <main(int, char**)>, structors=<optimized out>) at bionic/libc/bionic/libc_init_dynamic.cpp:112
#48 0x00009188 in _start ()

Comment 6

[Benoit Girard (:BenWa)]

Can you get a backtrace each time http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#1255 is hit. Then once you hit the assertion the last backtrace from line 1255 will be the source of the error.

Comment 8

[Gregor Wagner [:gwagner]]

(In reply to Benoit Girard (:BenWa) from comment #6)
> Can you get a backtrace each time
> http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.
> cpp#1255 is hit. Then once you hit the assertion the last backtrace from
> line 1255 will be the source of the error.

That doesn't work. I hit it a few hundred times before reaching the assertion :(

Comment 9

[Benoit Girard (:BenWa)]

Why doesn't it work?

Comment 10

[Gregor Wagner [:gwagner]]

Here we go:

Breakpoint 1, nsDisplayListBuilder::IsInWillChangeBudget (this=this@entry=0xbea0e4b8, aFrame=0xb1179428) at ../../../layout/base/nsDisplayList.cpp:1258
1258	  mWillChangeBudget.Get(key, &budget);
#0  nsDisplayListBuilder::IsInWillChangeBudget (this=this@entry=0xbea0e4b8, aFrame=0xb1179428) at ../../../layout/base/nsDisplayList.cpp:1258
#1  0xb56d1ed2 in mozilla::ScrollFrameHelper::IsScrollingActive (this=0xb1179478, aBuilder=0xbea0e4b8) at ../../../layout/generic/nsGfxScrollFrame.cpp:4224
#2  0xb5679240 in IsAnimatedGeometryRoot (aParent=0x0, aFrame=0xb11799e8, this=0xbea0e4b8) at ../../../layout/base/nsDisplayList.cpp:1138
#3  nsDisplayListBuilder::IsAnimatedGeometryRoot (this=0xbea0e4b8, aFrame=0xb11799e8, aParent=0x0) at ../../../layout/base/nsDisplayList.cpp:1106
#4  0xb5679528 in nsDisplayListBuilder::AutoBuildingDisplayList::AutoBuildingDisplayList (this=0xbea0bca0, aBuilder=0xbea0e4b8, aForChild=0xb11799e8, aDirtyRect=..., aIsRoot=true) at ../../../layout/base/nsDisplayList.h:577
#5  0xb56dad74 in mozilla::ScrollFrameHelper::AppendScrollPartsTo (this=this@entry=0xb1179478, aBuilder=aBuilder@entry=0xbea0e4b8, aDirtyRect=..., aLists=..., aUsingDisplayPort=aUsingDisplayPort@entry=true, aCreateLayer=aCreateLayer@entry=false, aPositioned=aPositioned@entry=true) at ../../../layout/generic/nsGfxScrollFrame.cpp:2623
#6  0xb56db4f6 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb1179478, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:3095
#7  0xb56d9c24 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1ce7120, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=aChild@entry=0xb1179ba8, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=4) at ../../../layout/generic/nsFrame.cpp:2460
#8  0xb56b2afa in DisplayLine (aBuilder=aBuilder@entry=0xbea0e4b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbea0c2a8: 0, aLists=..., aFrame=aFrame@entry=0xb1ce7120, aTextOverflow=0x0) at ../../../layout/generic/nsBlockFrame.cpp:6244
#9  0xb56be79e in nsBlockFrame::BuildDisplayList (this=0xb1ce7120, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#10 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=0xb1ce7010, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#11 0xb56db2c8 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb1ce7060, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:3017
#12 0xb56d90e6 in nsIFrame::BuildDisplayListForStackingContext (this=this@entry=0xb1ce7010, aBuilder=aBuilder@entry=0xbea0e4b8, aDirtyRect=..., aList=aList@entry=0xbea0cb20) at ../../../layout/generic/nsFrame.cpp:2052
#13 0xb56d9b02 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1df4d40, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=aChild@entry=0xb1ce7180, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=4) at ../../../layout/generic/nsFrame.cpp:2406
#14 0xb56b2afa in DisplayLine (aBuilder=aBuilder@entry=0xbea0e4b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbea0ce20: -1294854256, aLists=..., aFrame=aFrame@entry=0xb1df4d40, aTextOverflow=0x0) at ../../../layout/generic/nsBlockFrame.cpp:6244
#15 0xb56be79e in nsBlockFrame::BuildDisplayList (this=0xb1df4d40, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#16 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=0xb1df4a78, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#17 0xb56db2c8 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb1df4ac8, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:3017
#18 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1df4288, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=aChild@entry=0xb1df4a78, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#19 0xb56b2afa in DisplayLine (aBuilder=aBuilder@entry=0xbea0e4b8, aLineArea=..., aDirtyRect=..., aLine=..., aDepth=aDepth@entry=0, aDrawnLines=@0xbea0d778: -1229212656, aLists=..., aFrame=aFrame@entry=0xb1df4288, aTextOverflow=0x0) at ../../../layout/generic/nsBlockFrame.cpp:6244
#20 0xb56be79e in nsBlockFrame::BuildDisplayList (this=0xb1df4288, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsBlockFrame.cpp:6336
#21 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1cab800, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=aChild@entry=0xb1df4288, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#22 0xb56b077e in nsCanvasFrame::BuildDisplayList (this=0xb1cab800, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsCanvasFrame.cpp:461
#23 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=0xb1caba00, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#24 0xb56daff4 in mozilla::ScrollFrameHelper::BuildDisplayList (this=0xb1caba50, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsGfxScrollFrame.cpp:2855
#25 0xb56d9bc6 in nsIFrame::BuildDisplayListForChild (this=this@entry=0xb1cab2b8, aBuilder=aBuilder@entry=0xbea0e4b8, aChild=<optimized out>, aDirtyRect=..., aLists=..., aFlags=aFlags@entry=0) at ../../../layout/generic/nsFrame.cpp:2441
#26 0xb570653e in ViewportFrame::BuildDisplayList (this=0xb1cab2b8, aBuilder=0xbea0e4b8, aDirtyRect=..., aLists=...) at ../../../layout/generic/nsViewportFrame.cpp:61
#27 0xb56d90e6 in nsIFrame::BuildDisplayListForStackingContext (this=this@entry=0xb1cab2b8, aBuilder=aBuilder@entry=0xbea0e4b8, aDirtyRect=..., aList=aList@entry=0xbea0e46c) at ../../../layout/generic/nsFrame.cpp:2052
#28 0xb56830f6 in nsLayoutUtils::PaintFrame (aRenderingContext=aRenderingContext@entry=0x0, aFrame=aFrame@entry=0xb1cab2b8, aDirtyRegion=..., aBackstop=aBackstop@entry=0, aFlags=772) at ../../../layout/base/nsLayoutUtils.cpp:2998
#29 0xb5690ffe in PresShell::Paint (this=0xb2caeca0, aViewToPaint=0xb1c31830, aDirtyRegion=..., aFlags=1) at ../../../layout/base/nsPresShell.cpp:6343
#30 0xb55023a8 in nsViewManager::ProcessPendingUpdatesPaint (this=0xb1c2e940, aWidget=aWidget@entry=0xb23a4d00) at ../../view/nsViewManager.cpp:443
#31 0xb55026f8 in nsViewManager::ProcessPendingUpdatesForView (this=this@entry=0xb2cd2260, aView=<optimized out>, aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at ../../view/nsViewManager.cpp:384
#32 0xb5502786 in nsViewManager::ProcessPendingUpdates (this=this@entry=0xb1c2e940) at ../../view/nsViewManager.cpp:1075
#33 0xb5629efa in nsRefreshDriver::Tick (this=0xb2cd2260, this@entry=0xb1be3340, aNowEpoch=<optimized out>, aNowTime=...) at ../../../layout/base/nsRefreshDriver.cpp:1358
#34 0xb562a51e in mozilla::RefreshDriverTimer::TickDriver (driver=0xb1be3340, jsnow=<optimized out>, now=..., now@entry=...) at ../../../layout/base/nsRefreshDriver.cpp:175
#35 0xb562a63c in mozilla::RefreshDriverTimer::Tick (this=0xb1be3340) at ../../../layout/base/nsRefreshDriver.cpp:166
#36 0xb47313ba in nsTimerImpl::Fire (this=0xb1bd4150) at ../../../xpcom/threads/nsTimerImpl.cpp:624
#37 0xb473153e in nsTimerEvent::Run (this=0xb1b440b0) at ../../../xpcom/threads/nsTimerImpl.cpp:717
#38 0xb472ed90 in nsThread::ProcessNextEvent (this=0xb384c230, aMayWait=<optimized out>, aResult=0xbea0ec97) at ../../../xpcom/threads/nsThread.cpp:830
#39 0xb47433fc in NS_ProcessNextEvent (aThread=0xb384c230, aMayWait=aMayWait@entry=false) at /Volumes/2mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:265
#40 0xb48f85a4 in mozilla::ipc::MessagePump::Run (this=0xb3801e20, aDelegate=0xbea0edf0) at ../../../ipc/glue/MessagePump.cpp:99
#41 0xb48e450c in MessageLoop::RunInternal (this=this@entry=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:233
#42 0xb48e4526 in RunHandler (this=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#43 MessageLoop::Run (this=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#44 0xb5505982 in nsBaseAppShell::Run (this=0xb2c6c460) at ../../widget/nsBaseAppShell.cpp:164
#45 0xb594d452 in XRE_RunAppShell () at ../../../toolkit/xre/nsEmbedFunctions.cpp:731
#46 0xb48f86d2 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0xb3801e20, aDelegate=0xbea0edf0) at ../../../ipc/glue/MessagePump.cpp:272
#47 0xb48e450c in MessageLoop::RunInternal (this=this@entry=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:233
#48 0xb48e4526 in RunHandler (this=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#49 MessageLoop::Run (this=this@entry=0xbea0edf0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#50 0xb594d3b2 in XRE_InitChildProcess (aArgc=<optimized out>, aArgv=<optimized out>, aGMPLoader=<optimized out>) at ../../../toolkit/xre/nsEmbedFunctions.cpp:568
#51 0x000092a8 in content_process_main (argc=6, argv=0xbea0f8e4) at ../../../ipc/app/../contentproc/plugin-container.cpp:216
#52 0xb6eee4a4 in __libc_init (raw_args=0xbea0f8e0, onexit=<optimized out>, slingshot=0x9309 <main(int, char**)>, structors=<optimized out>) at bionic/libc/bionic/libc_init_dynamic.cpp:112
#53 0x00009188 in _start ()

Program received signal SIGSEGV, Segmentation fault.
0xb565e4fe in nsDisplayListBuilder::AddToWillChangeBudget (this=this@entry=0xbea0e4b8, aFrame=aFrame@entry=0xb1ceaea0, aRect=...) at ../../../layout/base/nsDisplayList.cpp:1223
1223	  MOZ_ASSERT(!mWillChangeBudgetCalculated,

Comment 11

[Zac C (:zac)]

If you need a better STR, I'm getting this heavily on debug builds of desktopb2g on linux64 platform.

Comment 12

[Zac C (:zac)]

Apologies, comment #11 was referring to an old version of Gecko.

Comment 13

[Zac C (:zac)]

Attachment: gecko.log

Apologies for the flip-flop, I can replicate this on desktopb2g, linux64 debug. non-debug builds are fine.

It occurs exactly as per comment #1 - loading a panel in the Gaia Settings app causes the crash.



mozversion application_buildid: 20141203105457
mozversion application_changeset: 24b10dc8139d
mozversion application_display_name: B2G
mozversion application_id: {3c2e2abc-06d4-11e1-ac3b-374f68613e61}
mozversion application_name: B2G
mozversion application_remotingname: b2g
mozversion application_repository: https://hg.mozilla.org/integration/b2g-inbound
mozversion application_vendor: Mozilla
mozversion application_version: 37.0a1
mozversion gaia_date: 1417633514
mozversion platform_buildid: 20141203105457
mozversion platform_changeset: 24b10dc8139d
mozversion platform_repository: https://hg.mozilla.org/integration/b2g-inbound
mozversion platform_version: 37.0a1

Comment 14

[Zac C (:zac)]

Gregor, were you on a debug build when you had this crash?

Comment 15

[Gregor Wagner [:gwagner]]

(In reply to Zac C (:zac) from comment #14)
> Gregor, were you on a debug build when you had this crash?

Yes this happened with a debug gecko.

Comment 17

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I'm constantly running into this bug when opening the Bluetooth pane in Settings.

Comment 18

[Botond Ballo [:botond]]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #17)
> I'm constantly running into this bug when opening the Bluetooth pane in
> Settings.

I run into this all the time too. I worked around it by disabling the assertion. BenWa said doing so is harmless.

Comment 19

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Bisecting this bug returned

Änderung:        216814:42c5ee6094ee
Nutzer:          David Anderson <[e-mail]>
Datum:           Thu Nov 20 16:58:18 2014 -0800
Zusammenfassung: Cache the current animated geometry root in nsDisplayListBuilder. (bug 1101260 part 1, r=roc)

Comment 20

[Thomas Zimmermann [:tzimmermann] [:tdz]]

After weeks, this problem still exists. David, this is a regression from one of your patches. Can you please have look at this bug?

Comment 21

[David Anderson [:dvander] - inactive, e-mail if emergency]

roc - It looks like the problem here is that IsScrollingActive() (which is called to determine the animated geometry root) calls IsInWillChangeBudget, before nsGfxScrollFrame gets a chance to add itself to the budget.

We could call IsMaybeScrollingActive instead (which skips the budget check and assumes we're always in-budget). But then it's possible we determine an incorrect animated geometry root, since we think the frame is active during some parts of displaylist construction and inactive later.

Any thoughts? The budget mechanism seems rather finicky so I'm not sure what the best fix is.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Botond Ballo [:botond] from comment #18)
> I run into this all the time too. I worked around it by disabling the
> assertion. BenWa said doing so is harmless.

A great example of a case where an assertion should be non-fatal :-).

(In reply to David Anderson [:dvander] from comment #21)
> roc - It looks like the problem here is that IsScrollingActive() (which is
> called to determine the animated geometry root) calls IsInWillChangeBudget,
> before nsGfxScrollFrame gets a chance to add itself to the budget.
> 
> We could call IsMaybeScrollingActive instead (which skips the budget check
> and assumes we're always in-budget). But then it's possible we determine an
> incorrect animated geometry root, since we think the frame is active during
> some parts of displaylist construction and inactive later.
> 
> Any thoughts? The budget mechanism seems rather finicky so I'm not sure what
> the best fix is.

This is a really tough problem.

We want to know about animated geometry roots during display list construction. But animated geometry roots depend on will-change budgeting, which depends on the contents of the display list.

This is going to be even more of a problem when we do incremental display list stuff and we need to know animated geometry roots when we don't even have a display list.

It seems to me we have to abandon the goal of having the will-change budgeting decision and the display list always be consistent. We should build a display list, check to see if it's over budget, and if it is, disable will-change in one or more documents, and rebuild the display list. will-change disabling would have to persist for a while to avoid continuous expensive rebuilding. BenWa, what do you think?

Comment 23

[David Anderson [:dvander] - inactive, e-mail if emergency]

How bad would it be to use heuristics that don't rely on the display list being built? Then we could just make the decision earlier. Or to ignore the suggestion at first and use the budget as feedback for the next time we paint.

Comment 24

[David Anderson [:dvander] - inactive, e-mail if emergency]

Also since this is annoying for b2g folks and it sounds like invasive changes are needed, is it okay to change this to NS_WARNING in the meantime?

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

NS_ASSERTION if that works for them.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to David Anderson [:dvander] from comment #23)
> How bad would it be to use heuristics that don't rely on the display list
> being built? Then we could just make the decision earlier. Or to ignore the
> suggestion at first and use the budget as feedback for the next time we
> paint.

Hmm. We could track all the frames with will-change, and recompute the will-change budget after every reflow, say. Doing it outside of display list construction would mean content outside the display port would count against the budget, but that's probably OK. In fact, that's probably good since it would make things more predictable. I like this idea!

Comment 27

[Benoit Girard (:BenWa)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22)
> A great example of a case where an assertion should be non-fatal :-).

Perhaps, but non-fatal means that no one will care when it regresses. If this assertion is hit then the will-change budget will be wrong.

> BenWa, what do you think?

We had discussed this approach before implementing what we have now. IIRC the reasoning was that this would cause a performance cliff for something that is perfectly normal. Authors shouldn't have to think about what we think is a reasonable budget for the device we run on. If we decide that the budget for a particularly device is much lower, such as 128 MB b2g, performance shouldn't be worse with out of budget will-change than it is had the will-change been removed.

We had discuss that the changes I made would be difficult to maintain but that it was worth while, at this point we just have one or two cases in the tree that need fixing. But if this design is not future proof maybe we don't have a ton of choice.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #26)
> Doing it outside of display list
> construction would mean content outside the display port would count against
> the budget, but that's probably OK. In fact, that's probably good since it
> would make things more predictable. I like this idea!

The down side is could lead the users to do their own viewport management and mask will-change for elements outside the viewport. This would pass on complexity to web authors and would cause undesirable behavior when we're rendering with a display port.

Down the road it will make it harder to make more intelligent, cost based, decisions on what and when we layerize elements. Something I was hopping we could eventually investigate more. 

How about an alternative suggestion based on my incomplete understanding on geometry roots: Whats the cost of setting up a geometry root if we don't create a layer? We could just create geometry roots for any will-change content and make sure they render correctly if we don't create a layer. Wouldn't that break the dependency and be future proof with the incremental display list?

Comment 28

[Gregor Wagner [:gwagner]]

Attachment: 1103106.diff

Comment 29

[Gregor Wagner [:gwagner]]

Attachment: 1103106.diff

Comment 30

[Benoit Girard (:BenWa)]

Comment on attachment 8546773 [details] [diff] [review]
1103106.diff

Review of attachment 8546773 [details] [diff] [review]:
-----------------------------------------------------------------

I can review this. Sorry for the hassle this has caused else where!

Comment 31

[Gregor Wagner [:gwagner]]

https://hg.mozilla.org/integration/b2g-inbound/rev/0bc29e98ceb4

Comment 32

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/0bc29e98ceb4

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Benoit Girard (:BenWa) from comment #27)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22)
> > A great example of a case where an assertion should be non-fatal :-).
> 
> Perhaps, but non-fatal means that no one will care when it regresses.

Patches that cause NS_ASSERTIONs to fire in automated tests are backed out, so NS_ASSERTION provides a significant level of regression protection.

I think it's futile to aim for more than that, given even good Gecko developers on the same team are patching the assertion out rather than "caring" (see comment #18). Trying to make people care by making the assertion fatal isn't working. And that may be a good thing, since I can easily believe Botond has more important things to work on.

> If this assertion is hit then the will-change budget will be wrong.

Sure.

> > BenWa, what do you think?
> 
> We had discussed this approach before implementing what we have now. IIRC
> the reasoning was that this would cause a performance cliff for something
> that is perfectly normal. Authors shouldn't have to think about what we
> think is a reasonable budget for the device we run on. If we decide that the
> budget for a particularly device is much lower, such as 128 MB b2g,
> performance shouldn't be worse with out of budget will-change than it is had
> the will-change been removed.
> 
> We had discuss that the changes I made would be difficult to maintain but
> that it was worth while, at this point we just have one or two cases in the
> tree that need fixing. But if this design is not future proof maybe we don't
> have a ton of choice.

Good points.

> How about an alternative suggestion based on my incomplete understanding on
> geometry roots: Whats the cost of setting up a geometry root if we don't
> create a layer? We could just create geometry roots for any will-change
> content and make sure they render correctly if we don't create a layer.
> Wouldn't that break the dependency and be future proof with the incremental
> display list?

Unlike other layerization decisions we make, this is not easy to revert at the last minute in FrameLayerBuilder. FrameLayerBuilder assigns items to ThebesLayers so that items in the same ThebesLayer must have the same animated geometry root. So, to maintain this invariant and reduce the number of layers we have to effectively split the current notion of animated geometry root into "tentative animated geometry root" and "actual animated geometry root", and that adds significant complexity and might even not work at all.

> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #26)
> > Doing it outside of display list
> > construction would mean content outside the display port would count against
> > the budget, but that's probably OK. In fact, that's probably good since it
> > would make things more predictable. I like this idea!
> 
> The down side is could lead the users to do their own viewport management
> and mask will-change for elements outside the viewport. This would pass on
> complexity to web authors and would cause undesirable behavior when we're
> rendering with a display port.

We could do comment #26 but exclude frames which are obviously totally outside the displayport from being part of the budget. Frames which are covered by other opaque frames, or clipped out, would still be counted against the budget, though we could alter that depending on how fancy we want to be.

> Down the road it will make it harder to make more intelligent, cost based,
> decisions on what and when we layerize elements. Something I was hopping we
> could eventually investigate more.

I think there's a fundamental tension here between being intelligent and cost-based, and being understandable by authors, especially across devices/platforms. There's also a fundamental tension between being intelligent and cost-based and avoiding extra work when will-change is disabled --- since the more accurately we want to measure costs, the more work we have to do which is thrown away if we decide to disable will-change.

Comment 34

[Jesse Ruderman]

Attachment: fuzz testcase #1

If this is actually a different bug (triggering the same assertion), let me know and I'll file a new report.

Comment 35

[Gregor Wagner [:gwagner]]

This issue spams logcat a LOT. Could we get back to it?

Comment 37

[Benoit Girard (:BenWa)]

I've re-read the above and given it some thought. Our options:
1) Pretty much a no-go: Implement some maybe-geometry-root thing.
2) Run the display list code twice if out of budget. This means that for heavy desktop page on b2g, not only are we barely rendering them but we risk falling back out of budget and doing display list twice per frame on pages where we can afford it the least.
3) Revisit our decision to have will-change be all or nothing.

Assume that if the behavior we provide is: When you're out of budget, we let through elements summing up to the budget in an undefined order. In practice for us it will likely be that will-change: scroll-position; will get priority because of how our animated geometry root code runs so it will be relatively stable.

It's not much different for the author if he's getting some vs. no layer since it's an invisible change for him since we preserve the stacking behavior regardless. It also means that we don't run the risk of building the DL twice.

In practice this would mean simplifying the code budget code a little bit and removing the assertion.

:roc what do you think? If we're not happy with the above #3 then I'll look into implementing #2.

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The main problem I see with #3 is that it means the same frame may be a geometry root at one stage of painting and not be a geometry root at another stage of the same paint. That could be very confusing and complex to deal with.

How about #2, but we disable will-change persistently for documents containing will-change elements, starting with the deepest documents; i.e. don't disable will-change for a document if it has descendants that have undisabled will-change.

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I guess we can fix #3 by making a decision once and then storing state to ensure we don't change it during that paint.

Comment 40

[Benoit Girard (:BenWa)]

Attachment: MozReview Request: Bug 1103106 - Change will-change to be first-come, first-served. r=roc

Bug 1103106 - Change will-change to be first-come, first-served. r=roc

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8630128 [details]
MozReview Request: Bug 1103106 - Change will-change to be first-come, first-served. r=roc

https://reviewboard.mozilla.org/r/12687/#review11265

Ship It!

Comment 42

[Benoit Girard (:BenWa)]

I have this ready to push but I'm waiting on inbound to re-open.

Comment 43

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6882b193f008

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6882b193f008