1612454 - Crash in [@ __memcpy_sse2_unaligned_erms | mozilla::AudioBufferWriter::Write]

Status: RESOLVED FIXED

(Core :: Audio/Video: cubeb, defect, P3)

Description

[Andrew McCreight [:mccr8]]

This bug is for crash report bp-4b8a01b0-fb4f-4491-9dab-2ee900200130.

Top 10 frames of crashing thread:

0 libc-2.30.so __memcpy_sse2_unaligned_erms 
1 libxul.so mozilla::AudioBufferWriter::Write dom/media/AudioStream.h:151
2 libxul.so mozilla::AudioStream::GetUnprocessed dom/media/AudioStream.cpp:522
3 libxul.so mozilla::AudioStream::DataCallback dom/media/AudioStream.cpp:610
4 libxul.so std::panicking::try::do_call media/audioipc/client/src/stream.rs:113
5 libxul.so <futures_cpupool::MySender<F, core::result::Result<<F as futures::future::Future>::Item, <F as futures::future::Future>::Error>> as futures::future::Future>::poll third_party/rust/futures-cpupool/src/lib.rs:325
6 libxul.so futures::task_impl::std::Run::run 
7 libxul.so std::sys_common::backtrace::__rust_begin_short_backtrace src/libstd/sys_common/backtrace.rs:126
8 libxul.so core::ops::function::FnOnce::call_once{{vtable.shim}} src/libcore/ops/function.rs:227
9 libxul.so <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once src/liballoc/boxed.rs:922

Only a few installation times, so I don't know if it is just a hardware error on one person's machine.

Comment 1

[Gabriele Svelto [:gsvelto]]

The crash cause is SIGBUS which can be only two cases on Linux: either an out-of-memory error (then the signal was sent by the OOM killer) or we've accessed a file that we had mmap()'d and the section we tried to access had been truncated. I'm inclined to think that this might be an OOM crash - and thus not actionable - but I'm not sure because I don't know if this code could be accessing a mapped file.

Comment 2

[Paul Adenot (:padenot)]

This might be an mmap issue. This might be both reading and writing to shmems: reading from RDD shmem (since jya did the zero-copy path there), writing to audioipc shmem. I saw something like this a few weeks/months back, iirc, but the traffic was super low.

However those shmems are not backed by files I think, dunno if we get SIGBUS then? Gabriele, do you know?

Comment 3

[Gabriele Svelto [:gsvelto]]

SIGBUS shows up in mappings only when there's some kind of file backing involved, otherwise it's certainly an OOM.

Comment 4

[Paul Adenot (:padenot)]

Scratch that, they are file backed on the audioipc side: https://searchfox.org/mozilla-central/source/media/audioipc/audioipc/src/shm.rs#96

Comment 5

[Gabriele Svelto [:gsvelto]]

Alright, is it possible that the file backing gets truncated? Or maybe we're hitting bug 1245239? What I found suspicious about the crashes is the the crash address always ends with 10 or f0. That seems a bit odd. Generally speaking regular OOM crashes have the crashing address set to a multiple of the page size though I don't think that's always guaranteed.

Comment 6

[Paul Adenot (:padenot)]

It's possible to rm the file, I think? Matthew will know for sure.

Comment 7

[Matthew Gregan [:kinetik]]

AudioIPC's shm file is unlinked immediately after mmap. There's a good chance this is a variant of bug 1245239, so I'll investigate that first. Thanks for the tip!

Comment 8

[Botond Ballo [:botond]]

I ran into this today. It seems to have to do with not having space on my root partition -- freeing up space on my root partition made the issue go away.

It would be nice if running out of space on the root partition was handled more gracefully than a crash.

Comment 9

[Alex Chronopoulos [:achronop]]

(In reply to Botond Ballo [:botond] from comment #8)

I ran into this today. It seems to have to do with not having space on my root partition -- freeing up space on my root partition made the issue go away.

Thank you for the comment. Can you please tell us what exactly you were doing when it crashed. Any kind of steps or anything similar would be extremely useful. I could fill up my root partition and try it. If we can repro we will be able to do something about it. Thank you in advance.

Comment 10

[Botond Ballo [:botond]]

My recollection is that the crash happened within a second or so of trying to start an HTML5 video.

Comment 11

[Matthew Gregan [:kinetik]]

Attachment: GitHub Pull Request

PR #90 should address this.

Comment 13

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #11)

PR #90 should address this.

Which will land via bug 1619780.

Comment 14

[Matthew Gregan [:kinetik]]

Fix landed via bug 1619780.

Comment 15

[Julien Cristau [:jcristau]]

Is the fix safe/worth an uplift or can it ride the trains to 76?

Comment 16

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 17

[Matthew Gregan [:kinetik]]

(In reply to Julien Cristau [:jcristau] from comment #15)

Is the fix safe/worth an uplift or can it ride the trains to 76?

I think it's better to ride the trains if we can. It would be possible to cherry-pick a safe subset of the changes for uplift, if necessary.