Closed Bug 1086670 Opened 5 years ago Closed 5 years ago

crash in @0x0 | mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::ThebesLayer*, unsigned int)

Categories

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

34 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: lizzard, Assigned: nical)

References

Details

(Keywords: crash, topcrash-win, Whiteboard: [leave-open])

Crash Data

Attachments

(3 files, 1 obsolete file)

This bug was filed from the Socorro interface and is 
report bp-f4c555ab-d455-468b-8ca4-9c0fe2141020.
=============================================================
This is the #7 topcrash for Firefox 34.0b1 with 968/36533 crashes in the last 7 days. They are all on the 20141014134955 build.  

Crashing thread:

0 		@0x0 	
1 	xul.dll 	mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::ThebesLayer*, unsigned int) 	gfx/layers/RotatedBuffer.cpp
2 	xul.dll 	mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer(mozilla::layers::ThebesLayer*, unsigned int) 	gfx/layers/client/ContentClient.h
3 	xul.dll 	mozilla::layers::ClientThebesLayer::PaintThebes() 	gfx/layers/client/ClientThebesLayer.cpp
4 	xul.dll 	mozilla::layers::ClientThebesLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) 	gfx/layers/client/ClientThebesLayer.cpp
5 	xul.dll 	mozilla::layers::ClientContainerLayer::RenderLayer() 	gfx/layers/client/ClientContainerLayer.h
6 	xul.dll 	mozilla::layers::Layer::ApplyPendingUpdatesForThisTransaction() 	gfx/layers/Layers.cpp
7 	xul.dll 	mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/client/ClientLayerManager.cpp
:nical, is this similar/same to the one you recently dealt with?
Flags: needinfo?(nical.bugzilla)
(In reply to Milan Sreckovic [:milan] from comment #1)
> :nical, is this similar/same to the one you recently dealt with?

Looks like a new one.
Assignee: nobody → nical.bugzilla
Flags: needinfo?(nical.bugzilla)
So at the crash site we are dereferencing a null pointer to one of the two DrawTargets of a component alpha pair. as it turns out we managed to create the first texture and not the second one. The stack doesn't provide any information about what caused the failure to create the second DrawTarget. Could be OOM, or maybe something else.
If we just early return, the content of the layer will not be rendered or updated properly which could make the browser glitchy or unusable. If we just crash there, well we have a lot of crashes.

I am looking into adding more fatal assertions in the code that is involved, to see if it turns out to be an error in code that is called beforehand. If it's OOM we don't have a good way to fix it in the short term so we may want to just glitch rather than crash (not sure, although we already do if we fail to create the first texture of the pair).
Let's add gfxCriticalError() as well. If it's OOM situation, glitchy may be better than crashing, especially if it's a temporary situation.
Duplicate of this bug: 1098052
Bas, can I haz a review?
Attached patch updated patchSplinter Review
This patch doesn't attempt to paper over the issue, but adds some logging that will help with the investigation.
Attachment #8513623 - Attachment is obsolete: true
Attachment #8513623 - Flags: review?(bas)
Attachment #8523932 - Flags: review?(bas)
Attachment #8523932 - Flags: review?(bas) → review+
Up to you.
At the moment we don't assert in gfxCriticalError but we'll most probably do soon and I am more interested in getting the gfxCriticalError data in the app notes.
Attachment #8525422 - Flags: review?(bas)
Attachment #8525422 - Flags: review?(bas) → review+
Landed the patch without the MOZ_ASSERTS https://hg.mozilla.org/integration/mozilla-inbound/rev/ef55c94657dc
Whiteboard: [leave-open]
Interestingly nothing in the appnotes since the patch landed

https://crash-stats.mozilla.com/search/?signature=~mozilla%3A%3Alayers%3A%3ARotatedContentBuffer%3A%3ABeginPaint&version=35.0a2&build_id=%3E20141120000000&_facets=signature&_columns=version&_columns=build_id&_columns=app_notes

If we don't restrict to build ids containing the patch, there are some E_OUTOFMEMORY D2D errors in the app notes but not as many as I expected.
I was silly enough to forget D2D 1.1 in the previous patch, so lots of possible interesting code paths wouldn't have shown in the app notes. This patch will log if we fail to create a D2D1.1 DrawTarget.
Attachment #8528657 - Flags: review?(bas)
Attachment #8528657 - Flags: review?(bas) → review?(jmuizelaar)
Attachment #8528657 - Flags: review?(jmuizelaar) → review+
Crash Signature: [@ @0x0 | mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::ThebesLayer*, unsigned int)] → [@ @0x0 | mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::ThebesLayer*, unsigned int)] [@ mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::ThebesLayer*, unsigned int)]
No crashes with this signature since 34?
(In reply to Milan Sreckovic [:milan] from comment #16)
> No crashes with this signature since 34?

It's entirely possible that it migrated to bug 1081911 which is still high in the latest 36 beta.
This isn't happening in post-34, so I'm closing the bug as WFM.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.