1553664 - Crash in MappedYCbCrTextureData::CopyInto from CamerasChild::RecvDeliverFrame

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

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

Top 10 frames of crashing thread:

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

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

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

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.

Comment 2

[Ryan Hunt [:rhunt]]

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?

Comment 3

[Nicolas Silva [:nical]]

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.

Comment 4

[Gabriele Svelto [:gsvelto]]

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

Comment 5

[Gabriele Svelto [:gsvelto]]

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.

Comment 6

[Timothy Nikkel (:tnikkel)]

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

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.