This bug was filed from the Socorro interface and is report bp-e0273ac5-81e2-465a-9e8f-4450f2141023. =============================================================

Comment * using pdf.js URLS are all PDF's

Reproducible on my Galaxy S5 (4.4.2) with Nightly (10/30) scrolling through http://mozilla.github.io/pdf.js/web/viewer.html I'll grab a window shortly.

Last good revision: 820188e039a0 First bad revision: 1abfecf86c50 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=820188e039a0&tochange=1abfecf86c50 Regression from bug 1082530

Note that on builds prior to this window, this test-case URL on this bug (PDF.JS Viewer) page still does cause what looks like an OOM during scrolling, but break-pad doesn't show up at all on Android for that

As always seems to be the case when I work on crash reports, the stacks are busted. I don't see any obvious reason why the blamed changes would cause this, other than maybe the position of things changing in the binaries, so a different symbol getting blamed. I'm in the process of getting a local debug build, but just bumped into bug 1083116.

Based on an assertion I saw fail, working back to fill in the stack I think the top frames are: ImageHost::GenEffect http://hg.mozilla.org/mozilla-central/annotate/2114ef80f6ae/gfx/layers/composite/ImageHost.cpp#l282 CanvasLayerComposite::GenEffectChain http://hg.mozilla.org/mozilla-central/annotate/2114ef80f6ae/gfx/layers/composite/CanvasLayerComposite.cpp#l154 SenderHelper::SendLayer http://hg.mozilla.org/mozilla-central/annotate/2114ef80f6ae/gfx/layers/LayerScope.cpp#l728 LayerScope::SendLayer http://hg.mozilla.org/mozilla-central/annotate/2114ef80f6ae/gfx/layers/LayerScope.cpp#l951 Then it gets confusing since the only caller of LayerScope::SendLayer appears to be in widget/gonk/HwcComposer2D.cpp, which presumably isn't used by Fennec. I'm guessing callers of this Send stuff are also generated somewhere. The assertion that I saw fail is the MOZ_ASSERT(!mIsConsumerAcquired) in mozilla::gl::SharedSurface::ConsumerAcquire: http://hg.mozilla.org/mozilla-central/annotate/7e3c85754d32/gfx/gl/SharedSurface.h#l106 The stack at the time was: mozilla::gl::SharedSurface::ConsumerAcquire mozilla::layers::SharedSurfaceTextureHost::Lock mozilla::layers::ImageHost::Lock mozilla::layers::AutoLockCompositableHost::AutoLockCompositableHost mozilla::layers::ImageHost::Composite mozilla::layers::CanvasLayerComposite::RenderLayer mozilla::layers::RenderLayers<mozilla::layers::ContainerLayerComposite> mozilla::layers::ContainerRender<mozilla::layers::ContainerLayerComposite> mozilla::layers::ContainerLayerComposite::RenderLayer mozilla::layers::RenderLayers<mozilla::layers::ContainerLayerComposite> mozilla::layers::ContainerRender<mozilla::layers::ContainerLayerComposite> mozilla::layers::ContainerLayerComposite::RenderLayer mozilla::layers::LayerManagerComposite::Render mozilla::layers::LayerManagerComposite::EndTransaction mozilla::layers::LayerManagerComposite::EndEmptyTransaction mozilla::layers::CompositorParent::CompositeToTarget mozilla::layers::CompositorParent::CompositeCallback DispatchToMethod<mozilla::layers::CompositorParent, void (mozilla::layers::CompositorParent::*)(mozilla::TimeStamp), mozilla::TimeStamp> RunnableMethod<mozilla::layers::CompositorParent, void (mozilla::layers::CompositorParent::*)(mozilla::TimeStamp), Tuple1<mozilla::TimeStamp> >::Run MessageLoop::RunTask

Jeff, you added this assertion. Can you say whether this null-deref is likely to be a cause of it's failure, or what we can do here?

The assertion failure will be caused by a mismatch of ConsumerAcquire()/ConsumerRelease() pairs. If you can reproduce this locally than you should be able to just match up calls to these functions and see where it's missing one.

This doesn't really seem to be happening any more. It's certainly no longer a top crash.