Closed Bug 1553664 Opened 4 years ago Closed 4 months ago

Crash in MappedYCbCrTextureData::CopyInto from CamerasChild::RecvDeliverFrame


(Core :: Graphics, defect, P3)




Tracking Status
firefox72 --- affected


(Reporter: emilio, Unassigned)



(Keywords: crash)

Crash Data

This bug is for crash report bp-b206311b-2b61-497c-a0b7-2978b0190522.

Top 10 frames of crashing thread:

1 mozilla::layers::MappedYCbCrTextureData::CopyInto gfx/layers/client/TextureClient.h:157
2 mozilla::layers::UpdateYCbCrTextureClient gfx/layers/client/TextureClient.cpp:1706
3 mozilla::layers::SharedPlanarYCbCrImage::CopyData gfx/layers/ipc/SharedPlanarYCbCrImage.cpp:78
4 mozilla::MediaEngineRemoteVideoSource::DeliverFrame dom/media/webrtc/MediaEngineRemoteVideoSource.cpp:581
5 non-virtual thunk to mozilla::MediaEngineRemoteVideoSource::DeliverFrame dom/media/webrtc/MediaEngineRemoteVideoSource.cpp
6 mozilla::camera::CamerasChild::RecvDeliverFrame dom/media/systemservices/CamerasChild.cpp:574
7 mozilla::camera::PCamerasChild::OnMessageReceived ipc/ipdl/PCamerasChild.cpp:470
8 mozilla::ipc::PBackgroundChild::OnMessageReceived ipc/ipdl/PBackgroundChild.cpp:4717
9 mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2158

I just got this crash when I was trying to use Not sure it's quite actionable as-is, but I guess I'd report it anyhow.

See Also: → 1549316

Without knowing much about the gfx side, I wonder if the issue could also be there. We're trying to copy into a mapped texture, but doing a bad access. Bug 1549316 has comments speaking to that. I'm going to move this to gfx on that basis.

Component: Audio/Video → Graphics
Crash Signature: [@] [@ mozilla::layers::MappedYCbCrTextureData::CopyInto] → [@] [@ mozilla::layers::MappedYCbCrTextureData::CopyInto] [@ memcpy | mozilla::layers::MappedYCbCrChannelData::CopyInto]

Nical, it looks like we're successfully locking the texture and successfully mapping the contents, but somehow getting a SIGBUS failure. Do you have any insights into what could be happening?

Flags: needinfo?(nical.bugzilla)
Priority: -- → P3

This looks like an OOM situation. My understanding is that the way shmems work on linux, with open+ftruncate+mmap still allocates pages lazily and failures to allocate a page results in a SIGBUS.

Flags: needinfo?(nical.bugzilla)

There's a WIP patch to fail early and prevent this in bug 1245239 but it's never been finished.

Depends on: 1245239
Crash Signature: [@] [@ mozilla::layers::MappedYCbCrTextureData::CopyInto] [@ memcpy | mozilla::layers::MappedYCbCrChannelData::CopyInto] → [@] [@ mozilla::layers::MappedYCbCrTextureData::CopyInto] [@ memcpy | mozilla::layers::MappedYCbCrChannelData::CopyInto] [@ mozilla::layers::UpdateYCbCrTextureClient ]

We have better Linux signatures for this thanks to the Ubuntu/Debian symbol scraping. I've quickly eyeballed the crashes and they all have the same characteristics: page-aligned address & SIGBUS pointing to an OOM crash. It would be nice to add memory measurements like we have on Windows to confirm that these are indeed OOMs.

Crash Signature: [@] [@ mozilla::layers::MappedYCbCrTextureData::CopyInto] [@ memcpy | mozilla::layers::MappedYCbCrChannelData::CopyInto] [@ mozilla::layers::UpdateYCbCrTextureClient ] → [@ memcpy | mozilla::layers::MappedYCbCrChannelData::CopyInto] [@ __memcpy_sse2_unaligned_erms | mozilla::layers::MappedYCbCrChannelData::CopyInto] [@ __memcpy_ssse3 | mozilla::layers::MappedYCbCrChannelData::CopyInto] [@ mozilla::layers::MappedYCbCrTe…
See Also: → 1645591
QA Whiteboard: qa-not-actionable
Severity: critical → S2

No crashes on crash stats, decreasing severity -> S3.

Severity: S2 → S3

Closing because no crashes reported for 12 weeks.

Closed: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.