Failed assertion: mROFrontBuffer.type() == OptionalThebesBuffer::TThebesBuffer with graphics branch on b2g

RESOLVED WORKSFORME

Status

()

Core
Graphics: Layers
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: bjacob, Unassigned)

Tracking

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Make a debug build with the graphics branch on b2g.

Get this on startup:

Here mROFrontBuffer.mType is mozilla::layers::OptionalThebesBuffer::T__None  (0)

@nrc, nical, Bas: any idea where to look?


[New Thread 2431.2450]
ShadowLayerForwarder::Connect(Compositable)

Program received signal SIGSEGV, Segmentation fault.
0x41940390 in mozilla::layers::ContentClientDirect::SyncFrontBufferToBackBuffer (this=0x47d3d7c0)
    at /hack/mozilla-graphics/gfx/layers/ContentClient.cpp:235
235         MOZ_ASSERT(mROFrontBuffer.type() == OptionalThebesBuffer::TThebesBuffer);
(gdb) bt
#0  0x41940390 in mozilla::layers::ContentClientDirect::SyncFrontBufferToBackBuffer (this=0x47d3d7c0)
    at /hack/mozilla-graphics/gfx/layers/ContentClient.cpp:235
#1  0x41919cd8 in mozilla::layers::BasicThebesLayer::PaintThebes (this=0x44c465b0, aContext=0x47de0190, 
    aMaskLayer=<value optimized out>, aCallback=<value optimized out>, aCallbackData=0xbeb3ee28, 
    aReadback=0xbeb3e594) at /hack/mozilla-graphics/gfx/layers/basic/BasicThebesLayer.cpp:84
#2  0x4191a3fe in mozilla::layers::BasicShadowableThebesLayer::PaintThebes (this=0x44c465b0, aContext=0x47de0190, 
    aMaskLayer=<value optimized out>, 
    aCallback=0x40b99525 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)>, aCallbackData=0xbeb3ee28, aReadback=0xbeb3e594)
    at /hack/mozilla-graphics/gfx/layers/basic/BasicThebesLayer.cpp:274
#3  0x419139e4 in mozilla::layers::BasicLayerManager::PaintSelfOrChildren (this=0x4461fef0, aPaintContext=..., 
    aGroupTarget=0x47de0190) at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:831
#4  0x41913fb6 in mozilla::layers::BasicLayerManager::PaintLayer (this=0x4461fef0, aTarget=0x47de0190, 
    aLayer=0x44c465b0, aCallback=<value optimized out>, aCallbackData=0xbeb3ee28, aReadback=0xbeb3e594)
    at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:938
#5  0x41913ab0 in mozilla::layers::BasicLayerManager::PaintSelfOrChildren (this=0x4461fef0, aPaintContext=..., 
    aGroupTarget=0x47de0190) at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:846
#6  0x41913fb6 in mozilla::layers::BasicLayerManager::PaintLayer (this=0x4461fef0, aTarget=0x47de0190, 
    aLayer=0x49be7400, aCallback=<value optimized out>, aCallbackData=0xbeb3ee28, aReadback=0x0)
    at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:938
#7  0x41914b28 in mozilla::layers::BasicLayerManager::EndTransactionInternal (this=0x4461fef0, 
    aCallback=<value optimized out>, aCallbackData=<value optimized out>, aFlags=<value optimized out>)
    at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:591
#8  0x41914c8a in mozilla::layers::BasicLayerManager::EndTransaction (this=0x99, aCallback=0xbeb3d968, 
    aCallbackData=0xf7e4deba, aFlags=123) at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:510
#9  0x41915190 in mozilla::layers::BasicShadowLayerManager::EndTransaction (this=0x99, aCallback=0xbeb3d968, 
    aCallbackData=0xf7e4deba, aFlags=123) at /hack/mozilla-graphics/gfx/layers/basic/BasicLayerManager.cpp:1148
#10 0x40bd0b7e in nsDisplayList::PaintForFrame (this=<value optimized out>, aBuilder=0xbeb3ee28, 
    aCtx=<value optimized out>, aForFrame=<value optimized out>, aFlags=13)
    at /hack/mozilla-graphics/layout/base/nsDisplayList.cpp:1169
#11 0x40bd0dba in nsDisplayList::PaintRoot (this=0xbeb3f1b0, aBuilder=0xbeb3ee28, aCtx=0x0, aFlags=13)
    at /hack/mozilla-graphics/layout/base/nsDisplayList.cpp:1030
#12 0x40be903e in nsLayoutUtils::PaintFrame (aRenderingContext=<value optimized out>, aFrame=0x4706d298, 
    aDirtyRegion=<value optimized out>, aBackstop=<value optimized out>, aFlags=772)
    at /hack/mozilla-graphics/layout/base/nsLayoutUtils.cpp:2049
#13 0x40bfc8c6 in PresShell::Paint (this=0x46f2e550, aViewToPaint=0x4715c240, aDirtyRegion=<value optimized out>, 
    aFlags=<value optimized out>) at /hack/mozilla-graphics/layout/base/nsPresShell.cpp:5414
#14 0x40fb7826 in nsViewManager::ProcessPendingUpdatesForView (this=0x4715dee0, aView=0x4715c240, 
    aFlushDirtyRegion=<value optimized out>) at /hack/mozilla-graphics/view/src/nsViewManager.cpp:400
#15 0x40fb78ce in nsViewManager::ProcessPendingUpdates (this=<value optimized out>)
    at /hack/mozilla-graphics/view/src/nsViewManager.cpp:1120
#16 0x40c06bb4 in nsRefreshDriver::Tick (this=<value optimized out>, aNowEpoch=986887259, aNowTime=...)
    at /hack/mozilla-graphics/layout/base/nsRefreshDriver.cpp:955
#17 0x40c0718c in mozilla::RefreshDriverTimer::TickDriver (aTimer=<value optimized out>, 
    aClosure=<value optimized out>) at /hack/mozilla-graphics/layout/base/nsRefreshDriver.cpp:164
#18 mozilla::RefreshDriverTimer::Tick (aTimer=<value optimized out>, aClosure=<value optimized out>)
    at /hack/mozilla-graphics/layout/base/nsRefreshDriver.cpp:156
#19 mozilla::RefreshDriverTimer::TimerTick (aTimer=<value optimized out>, aClosure=<value optimized out>)
    at /hack/mozilla-graphics/layout/base/nsRefreshDriver.cpp:181
#20 0x4188c23e in nsTimerImpl::Fire (this=0x46f4e470) at /hack/mozilla-graphics/xpcom/threads/nsTimerImpl.cpp:482
#21 0x4188c434 in nsTimerEvent::Run (this=0x40444540) at /hack/mozilla-graphics/xpcom/threads/nsTimerImpl.cpp:565
(Reporter)

Updated

5 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM

Comment 1

5 years ago
First thing to check is that the Content Client and Host match - they should either both be *Texture or *Direct, you would get this if there was a mismatch.

If they do match, then perhaps initialising the Compositable includes sending an 'empty' message, that is with a null surface descriptor. Nical could confirm or deny that. In which case you would need to modify the assertion to take that into account.

If that is not the case, then perhaps the logic is wrong and sometimes the ContentHost can just send an 'empty' reply to the client. That would be surprising and probably a pain to fix.
I wonder if there was an error during the establishment of the ipdl stuff for the compositable. Can you check that before the crash, this compositable got something through ipdl to the other side and received something back? This mROFrontBuffer thing seems to be only set when receiving the reply from the compositor side so it looks like it didn't go through and failed silently because the compositable client/host pair would not match as nick suggested or the ipdl protocol did not connect properly (see CompositableClient::Connect).

In any case there should not be need for a message to pair up the compositables correctly, all the necessary info should only be in the compositable child/parent constructor.
I'm also getting mType mismatches in ShadowLayerForwarder::OpenDescriptor()
(Reporter)

Comment 4

5 years ago
Haven't gotten this assert failure in a long time now. Assuming it's gone.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.