Crash in MappedYCbCrTextureData::CopyInto from CamerasChild::RecvDeliverFrame
Categories
(Core :: Graphics, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | affected |
People
(Reporter: emilio, Unassigned)
References
Details
(Keywords: crash)
Crash Data
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.
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.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
There's a WIP patch to fail early and prevent this in bug 1245239 but it's never been finished.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•1 year ago
|
Comment 7•4 months ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•