Closed Bug 1565255 Opened 4 months ago Closed 4 months ago

Crash in [@ std::map<T>::_Try_emplace<T>]


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

Windows 10



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- fixed
firefox70 --- fixed


(Reporter: marcia, Assigned: sotaro)


(Keywords: crash, regression)

Crash Data


(1 file)

This bug is for crash report bp-0d1f96ac-6903-4cdc-84bf-167aa0190711.

Seen while looking at beta and nightly crash stats: Looks as if this regressed starting in 69 nightly. In Nightly 69 this appears to have started in 20190522093426 . Could Bug 1552734 be involved? ni on sotaro

Top 10 frames of crashing thread:

0 xul.dll static struct std::pair<std::_Tree_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<mozilla::layers::TextureClient*const, RefPtr<mozilla::layers::TextureClientHolder> > > > >, bool> std::map<mozilla::layers::TextureClient*, RefPtr<mozilla::layers::TextureClientHolder>, std::less<mozilla::layers::TextureClient*>, std::allocator<std::pair<mozilla::layers::TextureClient*const, RefPtr<mozilla::layers::TextureClientHolder> > > >::_Try_emplace<mozilla::layers::TextureClient*> vs2017_15.8.4/VC/include/map:228
1 xul.dll mozilla::layers::TextureClientRecycleAllocator::CreateOrRecycle gfx/layers/client/TextureClientRecycleAllocator.cpp:179
2 xul.dll mozilla::layers::D3D11YCbCrImage::CreateAndCopyDataToDXGIYCbCrTextureData gfx/layers/D3D11YCbCrImage.cpp:52
3 xul.dll mozilla::layers::ImageClient::CreateTextureClientForImage gfx/layers/client/ImageClient.cpp:121
4 xul.dll bool mozilla::layers::ImageClientSingle::UpdateImage gfx/layers/client/ImageClient.cpp:249
5 xul.dll mozilla::layers::ImageBridgeChild::UpdateImageClient gfx/layers/ipc/ImageBridgeChild.cpp:333
6 xul.dll nsresult mozilla::runnable_args_memfn<RefPtr<mozilla::layers::ImageBridgeChild>, void  media/mtransport/runnable_utils.h:148
7 xul.dll MessageLoop::DoWork ipc/chromium/src/base/
8 xul.dll base::MessagePumpDefault::Run ipc/chromium/src/base/
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/

Flags: needinfo?(sotaro.ikeda.g)

I'm kinda hoping bug 1562616 fixes this maybe?

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

I'm kinda hoping bug 1562616 fixes this maybe?

the fix for bug 1562616 is already in 69.0b4, but the crash volume for the signature here doesn't show a noticeable dent unfortunately.

Priority: -- → P2

It seems to be caused by oom. av1 video decoding in RDD process might use more memory. Then adding additional video frame memory might cause oom. Back out of Bug 1552734 could reduce memory usage. When Bug 1564646 is addressed. We could remove Bug 1552734 .

Flags: needinfo?(sotaro.ikeda.g)
Depends on: 1564646
Assignee: nobody → sotaro.ikeda.g

When Bug 1552734 was created, video with hardware texture did not need to re-build WR frame. To keep skipping WR frame re-build, Bug 1552734 was created. But it was changed. Since Bug 1531898, WR frame re-build always happens. Then we could remove Bug 1552734 now.

Bug 1561178 also affected how memory is used with RDD process.

Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

The frequency on Beta is high enough that we should try to fix the crash there as well. How do you want to approach fixing this crash on 69?

Flags: needinfo?(sotaro.ikeda.g)

Comment on attachment 9078566 [details]
Bug 1565255 - Backout Bug 1552734

Beta/Release Uplift Approval Request

  • User impact if declined: It might cause crash by oom during playing av1 videos.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The change just revert to before Bug 1552734.
  • String changes made/needed: none
Flags: needinfo?(sotaro.ikeda.g)
Attachment #9078566 - Flags: approval-mozilla-beta?

(In reply to Sotaro Ikeda [:sotaro] from comment #4)

Since Bug 1531898, WR frame re-build always happens.

This patch hasn't landed on 69. Is that going to cause problems if we uplift this to Beta?

Flags: needinfo?(sotaro.ikeda.g)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)

(In reply to Sotaro Ikeda [:sotaro] from comment #4)

Since Bug 1531898, WR frame re-build always happens.

This patch hasn't landed on 69. Is that going to cause problems if we uplift this to Beta?

Sorry, my comment was wrong. We do not need to uplift Bug 1531898. It addressed a bit different problem.

Since Bug 1558106 fix in 69, we always need to re-build WR frame if there is an update. A cost of re-building WR frame becomes smaller. Skipping re-build frame, but does WR rendering was already disabled by Bug 1559284. Then Bug 1552734 fix was not needed any more.

Bug 1552734 was added for skipping WR frame build if possible. It was not for reducing WR render.

Flags: needinfo?(sotaro.ikeda.g)
No longer depends on: 1564646

Bug 1531898 added a support of skip WR frame build and skip WR render if image update is not used in WR render. It is a new capability. Sorry for confusion.

Comment on attachment 9078566 [details]
Bug 1565255 - Backout Bug 1552734

Thanks for the clarification! Approved for 69.0b8.

Attachment #9078566 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.