This bug is for crash report bp-219f5d44-6b26-4e96-8d4c-aafae0190325.

Seen while looking at nightly crash stats - also present in 67: https://bit.ly/2U2w0Yz. 11 crashes/9 installations in the last 7 days.

Top 10 frames of crashing thread:

0 xul.dll static void core::ptr::real_drop_in_place<webrender_api::channel::MsgSender<webrender_api::api::ApiMsg>> src/libcore/ptr.rs:204
1 xul.dll void webrender_bindings::bindings::wr_api_delete gfx/webrender_bindings/src/bindings.rs:1230
2 xul.dll mozilla::wr::WebRenderAPI::~WebRenderAPI gfx/webrender_bindings/WebRenderAPI.cpp:352
3 xul.dll mozilla::wr::WebRenderAPI::Release gfx/webrender_bindings/WebRenderAPI.h:203
4 xul.dll nsTArray_Impl<RefPtr<mozilla::wr::WebRenderAPI>, nsTArrayInfallibleAllocator>::ClearAndRetainStorage xpcom/ds/nsTArray.h:1300
5 xul.dll void nsTArray_Impl<RefPtr<mozilla::wr::WebRenderAPI>, nsTArrayInfallibleAllocator>::Clear xpcom/ds/nsTArray.h:1763
6 xul.dll mozilla::layers::WebRenderBridgeParent::ClearResources gfx/layers/wr/WebRenderBridgeParent.cpp:2288
7 xul.dll class mozilla::ipc::IPCResult mozilla::layers::WebRenderBridgeParent::HandleShutdown gfx/layers/wr/WebRenderBridgeParent.cpp:384
8 xul.dll class mozilla::ipc::IPCResult mozilla::layers::WebRenderBridgeParent::RecvShutdown gfx/layers/wr/WebRenderBridgeParent.cpp:376
9 xul.dll mozilla::layers::PWebRenderBridgeParent::OnMessageReceived ipc/ipdl/PWebRenderBridgeParent.cpp:829

[Tracking Requested - why for this release]:
New crash introduced in 67.

Jessie, this is crashing in beta. No crashes with this signature in release. Could you please update with an assignee so we can get a fix to uplift to beta?

Sotaro, can you help determine why this crash is happening? Thank you!

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #0)

This bug is for crash report bp-219f5d44-6b26-4e96-8d4c-aafae0190325.

Seen while looking at nightly crash stats - also present in 67: https://bit.ly/2U2w0Yz. 11 crashes/9 installations in the last 7 days.

I looked into crashes of [@ core::ptr::real_drop_in_place<T> ] in 67. I did not saw the crash that have wr_api_delete. The all crashes in 67 happened at style code. The crash at style code is a different bug.

:marcia, did you see a crash that have wr_api_delete in a stack in 67?

I was having trouble sussing out the wr_api_delete stacks among the crashes (there are a few in 68). It looks as if may be some different crashes nested under the main signature. It also appears that some of the 67 crashes such as https://crash-stats.mozilla.com/report/index/d9291a0a-6061-4c9f-aac7-885d10190403 have possible UAF addresses, so I am marking this security sensitive.

Should core::ptr::real_drop_in_place<T> be added to the skip list so we can get better stacks?

Happy to file separate bugs for the different manifestations of this crash.

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #4)

Should core::ptr::real_drop_in_place<T> be added to the skip list so we can get better stacks?

Bug 1541474 is for it.

If Comment 3 is correct, the bug does not affect to 67.

From source code, I found one possibility.

There is a conflict of the followings.

• WebRenderBridgeParent::GetWebRenderAPI() call fron non-compositor thread
• Updating/Clearing of WebRenderBridgeParent::mApis on Compositor Thread

WebRenderBridgeParent::mApis is accessed from multiple threads, but the mApis are not protected by mutex. This reminds me Bug 1441498. See Bug 1441498 Comment 8.

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

If Comment 3 is correct, the bug does not affect to 67.

If Comment 7 is correct, the bug also affect to 67.

If comment 7 is correct, I don't think it sounds affect 67, because it is a regression from document splitting which only landed in 68. It might be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1538572#c5

If :dthayer is already working for the bug, it seems better that this bug is taken by :dthayer.

:dthayer, can you take this bug?

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

If :dthayer is already working for the bug, it seems better that this bug is taken by :dthayer.

:dthayer, can you take this bug?

The document splitting part shouldn't affect 67, but yes I am working on that part now.

Do we have a bug on file for the crashes in 67 that seem to be due to style code which you mention in comment 3?

(In reply to Doug Thayer [:dthayer] from comment #11)

Do we have a bug on file for the crashes in 67 that seem to be due to style code which you mention in comment 3?

We do not have a bug for style yet :( Before creating it, we found Bug 1541474.

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

(In reply to Doug Thayer [:dthayer] from comment #11)

Do we have a bug on file for the crashes in 67 that seem to be due to style code which you mention in comment 3?

We do not have a bug for style yet

I am going to create the bug.

Crated Bug 1541932 for style bug.

Assign to :dthayer since he is working for the bug by comment 11.

We've seen a lot of shutdown webrender crashes like bug 1540709 -- same thing?

(In reply to Daniel Veditz [:dveditz] from comment #16)

We've seen a lot of shutdown webrender crashes like bug 1540709 -- same thing?

No access - but if it's around a GetWebRenderAPI call, then likely yes.

CC'd you.

With bug 1541474 fix, the crash happens since 68.

It looks like the fix for bug 1538572 did indeed resolve this. Any objections to closing it?

Yea, we could close this bug, since there is no crash since bug 1538572 fix. Thanks!