1627821 - Crash in [@ __memmove_avx_unaligned_erms | mozilla::AudioStream::GetUnprocessed]

Status: RESOLVED DUPLICATE of bug 1612454

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

Description

[peilonrayz]

Reproduced in safe mode and on a fresh firefox-developer-edition install from arch.

I'm not sure what more information is needed or where to get it. Happy to provide information if needed.

This bug is for crash report bp-4ca41fa0-959b-4499-89ca-6dea00200406.

Top 10 frames of crashing thread:

0 libc-2.31.so __memmove_avx_unaligned_erms 
1 libxul.so mozilla::AudioStream::GetUnprocessed /build/firefox/src/firefox-74.0.1/dom/media/AudioStream.cpp:522
2 libxul.so mozilla::AudioStream::DataCallback /build/firefox/src/firefox-74.0.1/dom/media/AudioStream.cpp:610
3 libxul.so std::panicking::try::do_call /build/firefox/src/firefox-74.0.1/media/audioipc/client/src/stream.rs:113
4 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 /build/firefox/src/firefox-74.0.1/third_party/rust/futures-cpupool/src/lib.rs:325
5 libxul.so futures::task_impl::std::Run::run 
6 libxul.so std::sys_common::backtrace::__rust_begin_short_backtrace /build/rust/src/rustc-1.42.0-src/src/libstd/sys_common/backtrace.rs:129
7 libxul.so core::ops::function::FnOnce::call_once{{vtable.shim}} /build/rust/src/rustc-1.42.0-src/src/libcore/ops/function.rs:232
8 libxul.so <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once /build/rust/src/rustc-1.42.0-src/src/liballoc/boxed.rs:1015
9 libxul.so std::sys::unix::thread::Thread::new::thread_start /build/rust/src/rustc-1.42.0-src/src/libstd/sys/unix/thread.rs:80

Comment 1

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

Hi, could you provide the steps you're using to reproduce and the information from about:support?

Comment 2

[ray6y]

I am seeing the exact same bug when I try to play any media containing audio (HTML5 video, audio, Web Audio API)
Even doing new AudioContext() will crash the tab.

Comment 3

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

Marking this secure until we have a better understanding. about:support may still be useful.

Paul, any insight what's going on here? Looks like we've got a bad pointer to the chunks data during our callback.

Comment 4

[ray6y]

Attachment: about:support contents

I am seeing the exact same bug when I try to play any media containing audio (HTML5 video, audio, Web Audio API)
Even doing `new AudioContext()` will crash the tab.

Comment 5

[peilonrayz]

Sorry for the late reply. My computer decided that it would no longer boot after I powered down my install that night.

I can't provide steps to reproduce as to be completely honest I don't know what happened. And now my system works a-ok. The night before I was playing Steam games with Proton and recall only installing Lutris and Play on Linux. (With a full system update pacman -Syu) However they didn't have the game I wanted to play and so I went back on Steam.

The next day, after a reboot, Firefox would crash any tab that tried to play audio. And sometimes it would crash the current tab in addition to the page playing audio. I'm not sure what players the sites were using but they were Crunchyroll, Netflix and YouTube. Additionally when I got pings on Stack Exchange's chat network they would also crash the tab(s).

I am sorry to post a bug and then be absolutely no help. From my perspective this is a status:no-repro.

Comment 6

[ray6y]

I also have no clue what happened

Comment 7

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

To confirm, the crash happened in any tab using audio, and kept happening? Did it stop happening after a system restart?

Comment 8

[ray6y]

1. yes
2. yes it stopped after a system restart

Comment 9

[Paul Adenot (:padenot)]

This must because somehow audioipc can't get shared memory (because this is a SIGBUS), or because something wiped the files or something like this. I don't know why that would happen however.

Matthew, is that something that rings a bell? I remember you changed a few things lately.

Comment 10

[Matthew Gregan [:kinetik]]

This looks very similar to bug 1612454, which was fixed by the changes landed in bug 1619780 for Firefox 76 (beta).

I don't have access to clear the core-security flag, but this is not a security issue.

Paul's correct that this is a shared memory issue. AudioIPC maps (reserves) a fixed size shm region in both the server and client for sharing audio data. Before bug 1619780 landed, the OS faults in (commits) backing pages for the shm region on demand. If the OS ever fails to establish a backing upon accessing the affected page(s) we receive a SIGBUS and crash. Because we didn't pre-allocate the temporary file used to establish the shm region, it was possible for low space on the temporary file's filesystem to result in a failure to extend the shm region's backing.

The changes landed via bug 1619780 pre-allocate the entire temporary file during initialization, so we can handle this situation earlier. In addition (and more importantly, since this is now the effective default) we use memfd (if available; since Linux 3.17) which completely avoids the complexity of creating/pre-allocating/mapping/unlinking a file merely to set up an ~anonymous shm region.

I don't know the specific root cause for peilonrayz's or ray6y's crash yet, but the most likely explanation is low space in /tmp or wherever the $TMPDIR environment variable points (if set).

@peilonrayz and @ray6y, would you please try a newer Firefox build (beta 76 or nightly 77) and let us know if works for you?

Comment 11

[peilonrayz]

I am still on Firefox 75 and unable to reproduce this. So using 76 or 77 and not being able to reproduce wouldn't mean much.

• Talking about filling /tmp made me remember that I tried to either suspend or hibernate at some point which didn't work. I can't remember if it was that night. I setup a swap partition now because they both failed to work so this may be an unfair test.
  I've not reproduced this with either systemctl hibernate or systemctl suspend.

• I'm sceptical on my / partition being low space as it was a new install <7 days. Currently I have ~25% usage with roughly the same install.
  Would fallocate -l 100G /tmp/foo allow me to test this?

• I've reinstalled playonlinux and lutris and still not running into this.

Comment 12

[ray6y]

Just a question: Why does Firefox need disk space to play audio? Chromium doesn't.
@peilonrayz Find any way to get the / partition artificially full and test it. I am almost sure that it is because of a full disk and some bug in the code involving memory.

Comment 13

[ray6y]

Well... I would try Firefox beta, but there is not enough room to download it .-.
Time to clear out /tmp and artificially fill it again!

Comment 14

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

Tyson, could you un-restrict this bug, please? I don't appear to be able to. I restricted to be cautious, but comment 10 indicates this does not need to be.