Closed Bug 1483772 Opened 6 years ago Closed 6 years ago

Crash in mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback

Categories

(Core :: Graphics: Layers, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 --- fixed

People

(Reporter: jchen, Assigned: rhunt)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is
report bp-8ef3afa6-2d79-4e87-81eb-a07c90180815.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback gfx/layers/client/ClientPaintedLayer.cpp:172
1 xul.dll mozilla::layers::ClientContainerLayer::RenderLayer gfx/layers/client/ClientContainerLayer.h:58
2 xul.dll bool mozilla::layers::ClientLayerManager::EndTransactionInternal gfx/layers/client/ClientLayerManager.cpp:340
3 xul.dll mozilla::layers::ClientLayerManager::EndTransaction gfx/layers/client/ClientLayerManager.cpp:398
4 xul.dll nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:2759
5 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:3841
6 xul.dll mozilla::PresShell::Paint layout/base/PresShell.cpp:6349
7 xul.dll nsViewManager::ProcessPendingUpdatesForView view/nsViewManager.cpp:412
8 xul.dll void nsRefreshDriver::Tick layout/base/nsRefreshDriver.cpp:2042
9 xul.dll void mozilla::RefreshDriverTimer::TickRefreshDrivers layout/base/nsRefreshDriver.cpp:299

=============================================================

The crash seems to have started with the 20180815100249 Nightly and is the second top crash for that Nightly on Windows so far.

Ryan, does this look related to bug 1482956?
Flags: needinfo?(rhunt)
In bug 1482415 a special check was added for the case where we fail to allocate
a buffer and started an async task. This papered over one crash for another
as ClientPaintedLayer also assumes that if there is an async task there is
a capture. It'd be best to just null out mAsyncTask and keep those checks
as is.
This is because the fix in bug 1482415 was not comprehensive enough.
Flags: needinfo?(rhunt)
Comment on attachment 9001665 [details]
Bug 1483772 - Never have mAsyncTask be non-null when we cannot paint. r?nical

Nicolas Silva [:nical] has approved the revision.
Attachment #9001665 - Flags: review+
Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4841b3ddbacb
Never have mAsyncTask be non-null when we cannot paint. r=nical
https://hg.mozilla.org/mozilla-central/rev/4841b3ddbacb
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Assignee: nobody → rhunt
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: