Closed Bug 1110268 Opened 5 years ago Closed 5 years ago

crash in mozilla::layers::ShadowLayerForwarder::UpdatedTexture(mozilla::layers::CompositableClient*, mozilla::layers::TextureClient*, nsIntRegion*)


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

36 Branch
Windows NT
Not set



Tracking Status
firefox36 + verified
firefox37 --- verified


(Reporter: jbecerra, Assigned: nical)


(Keywords: crash, topcrash)

Crash Data


(1 file)

[Tracking Requested - why for this release]: A top crasher on Aurora 36.

This bug was filed from the Socorro interface and is 
report bp-5912f8fe-9044-4932-8e40-cb9752141205.

This is currently at #10 in the list of top crashers for Aurora 36. Although it isn't a new signature, we started getting a spike in the number of reports around 12/05. This is happening mostly on Windows 7 and XP installations. There are several dupes and a lot of comments from people who say they keep crashing several times in a short period of time. Nearly a third of the crashes reported were on installations with Adblock Plus (info from the correlations tab).

More reports at:

Frame	Module	Signature	Source
0	xul.dll	mozilla::layers::ShadowLayerForwarder::UpdatedTexture(mozilla::layers::CompositableClient*, mozilla::layers::TextureClient*, nsIntRegion*)	gfx/layers/ipc/ShadowLayers.cpp
1	xul.dll	mozilla::layers::CanvasClientSharedSurface::Update(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::ClientCanvasLayer*)	gfx/layers/client/CanvasClient.cpp
2	xul.dll	mozilla::layers::ClientCanvasLayer::RenderLayer()	gfx/layers/client/ClientCanvasLayer.cpp
3	xul.dll	mozilla::layers::ClientLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*)	gfx/layers/client/ClientLayerManager.h
4	xul.dll	mozilla::layers::ClientContainerLayer::RenderLayer()	gfx/layers/client/ClientContainerLayer.h
5	xul.dll	mozilla::layers::ClientLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*)	gfx/layers/client/ClientLayerManager.h
6	xul.dll	mozilla::layers::ClientContainerLayer::RenderLayer()	gfx/layers/client/ClientContainerLayer.h
7	xul.dll	mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)	gfx/layers/client/ClientLayerManager.cpp
8	xul.dll	mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)	gfx/layers/client/ClientLayerManager.cpp
9	xul.dll	nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int)	layout/base/nsDisplayList.cpp
10	xul.dll	nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int)	layout/base/nsLayoutUtils.cpp
11	xul.dll	PresShell::Paint(nsView*, nsRegion const&, unsigned int)	layout/base/nsPresShell.cpp
Topcrash, tracking.
Looks like TexClientFromReadback is returning a null texture in CanvasClientSharedSurface::Update. A debug build would have hit one of the various assertions around but not release builds. This would be caused by TextureClient::CreateForRawBufferAccess returning null which means we failed to allocate a MemoryTextureClient, so either the typically OOM case or perhaps a canvas that is unreasonably big.

Since this is specific to canvas, I am inclined to just paper over the issue, early-return and miss canvas frames when it happens.
Assignee: nobody → nical.bugzilla
Attachment #8538513 - Flags: review?(bas)
Attachment #8538513 - Flags: review?(bas) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Comment on attachment 8538513 [details] [diff] [review]
Don't crash release builds when failing to allocate a canvas surface

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: aurora top crasher.
[Describe test coverage new/current, TBPL]:
[Risks and why]: very low, if we go through the added code it means we are in a situation where we were going to crash anyway. Note that this is an issue that happens when running short on memory, so part of the crash volume will probably move to a different signature where OOM is more critical and can't be handled. That said, big WebGL canvases could cause this crash in cases where there is still enough memory for other things to function.
[String/UUID change made/needed]:
Attachment #8538513 - Flags: approval-mozilla-aurora?
Attachment #8538513 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.