Closed Bug 1091677 Opened 5 years ago Closed 5 years ago

crash in @0x0 | mozilla::layers::ImageHost::GenEffect(mozilla::gfx::Filter const&)

Categories

(Core :: Graphics: Layers, defect, critical)

36 Branch
All
Android
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1123084
Tracking Status
firefox36 --- affected
fennec 36+ ---

People

(Reporter: aaronmt, Unassigned)

References

()

Details

(Keywords: crash, regression, reproducible)

Crash Data

Attachments

(1 file)

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
Assignee: nobody → milan
Status: NEW → ASSIGNED
tracking-fennec: ? → 36+
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
Blocks: 1082530
Flags: needinfo?(jwatt)
Assignee: milan → jwatt
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.
Flags: needinfo?(jwatt)
Duplicate of this bug: 1093200
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?
Flags: needinfo?(jmuizelaar)
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.
Flags: needinfo?(jmuizelaar)
This doesn't really seem to be happening any more. It's certainly no longer a top crash.
Assignee: jwatt → nobody
tracking-fennec: 36+ → ?
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1123084
tracking-fennec: ? → 36+
You need to log in before you can comment on or make changes to this bug.