This is on Windows 10 using the latest nightly. STR: 1) Set media.windows-media-foundation.allow-d3d11-dxva = true 2) Restart Firefox 3) Play a video on YouTube Actual Results: Firefox crashes :( Expected Results: Firefox should not crash and the video should play.

Forgot to add the crash reports. bp-015d4f61-21fd-4e5a-9e5d-6e8592150822 bp-c71a8a7a-fe9f-4f53-9d89-a9df22150822

Matt, does this crash look like a regression from bug 1135935 or bug 1195527? Frame Module Signature Source 0 xul.dll mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame(mozilla::ipc::MessageChannel&, mozilla::ipc::Direction, IPC::Message const*) ipc/glue/MessageChannel.cpp 1 xul.dll mozilla::ipc::MessageChannel::Send(IPC::Message*) ipc/glue/MessageChannel.cpp 2 xul.dll mozilla::layers::PTextureChild::SendRecycleTexture(mozilla::layers::TextureFlags const&) obj-firefox/ipc/ipdl/PTextureChild.cpp 3 xul.dll mozilla::layers::TextureClientRecycleAllocator::CreateOrRecycle(mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) gfx/layers/client/TextureClientRecycleAllocator.cpp 4 xul.dll mozilla::layers::D3D11ShareHandleImage::SetData(mozilla::layers::D3D11ShareHandleImage::Data const&) gfx/layers/D3D11ShareHandleImage.cpp 5 xul.dll mozilla::D3D11DXVA2Manager::CopyToImage(IMFSample*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::ImageContainer*, mozilla::layers::Image**) dom/media/platforms/wmf/DXVA2Manager.cpp 6 xul.dll mozilla::WMFVideoMFTManager::CreateD3DVideoFrame(IMFSample*, __int64, mozilla::VideoData**) dom/media/platforms/wmf/WMFVideoMFTManager.cpp ...

This has been an issue for a few days, I only just got around to filing this now. I'm pretty sure this was happening before bug 1195527 landed. I'll try to find a regression range for this in a little bit. It's probably not a super high priority bug since the preference in question is experimental.

Guess I was wrong about this happening before bug 1195527, bug 1195527 is in this range so it could be the culprit. Last good revision: f384789a29dcfd514d25d4a16a97ec5309612d78 First bad revision: 29b2df16e961fbe9a379362ecba6f888d1754bc3 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f384789a29dcfd514d25d4a16a97ec5309612d78&tochange=29b2df16e961fbe9a379362ecba6f888d1754bc3 Sorry, mozregression failed to bisect inbound for this :(

Yeah, almost certainly bug 1195527, will take a look.

[Tracking Requested - why for this release]: This is a crash regression in Nightly 43 from bug 1195527.

This signature shows up for previous versions of Firefox as well. For example, here's a crash from today with 40.0.2: https://crash-stats.mozilla.com/report/index/a9725c52-1981-459d-84c5-6425f2150826

(In reply to Liz Henry (:lizzard) from comment #7) > This signature shows up for previous versions of Firefox as well. > For example, here's a crash from today with 40.0.2: > https://crash-stats.mozilla.com/report/index/a9725c52-1981-459d-84c5- > 6425f2150826 That specific report appears to be a Java plugin crash, which would be unrelated to this bug. Bug 1126268 also shares this same signature so I can only assume that this signature is fairly generic and probably covers a lot of different crashes.

Is this still reproducible with bug 1195527 fixed?

bug 1195527 is what caused this. Just tested again anyways, but it still crashes.

I don't think this needs to be tracking, it only happens with a custom pref set.

Comment on attachment 8659541 [details] [diff] [review] recycle-task Review of attachment 8659541 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3f02dab20a51 for m(2) orange: https://treeherder.mozilla.org/logviewer.html#?job_id=14084416&repo=mozilla-inbound