On Sun, Nov 10, 2019 at 12:58:50PM +0100, Tim van der Molen wrote: > Landry Breuil (2019-11-08 23:48 +0100): > > https://packages.rhaalovely.net/ has amd64 pkgs for 71.0b8 built from > > this branch, and i'm running it now. This needs more testing from anyone > > actually using firefox in weird environments so that we figure out more > > missing paths. > > Firefox doesn't play audio unless I add "/usr/lib r" to unveil.content. > I can reproduce this with an empty homedir and an audio-only .ogg file > in /tmp. > > Firefox writes this to stderr: > > [Child 99779, MediaDecoderStateMachine #1] WARNING: 17d3e855100 Can't get > cubeb context!: file > /usr/ports/pobj/firefox-71.0beta8/firefox-71.0/dom/media/AudioStream.cpp, > line 281 > [Child 99779, MediaDecoderStateMachine #1] WARNING: Decoder=17d3db0c800 > [OnMediaSinkAudioError]: file > /usr/ports/pobj/firefox-71.0beta8/firefox-71.0/dom/media/MediaDecoderStateMachine.cpp, > line 3639 > [Child 99779, MediaDecoderStateMachine #1] WARNING: Decoder=17d3db0c800 > Decode error: NS_ERROR_DOM_MEDIA_MEDIASINK_ERR (0x806e000b) - > OnMediaSinkAudioError: file > /usr/ports/pobj/firefox-71.0beta8/firefox-71.0/dom/media/MediaDecoderStateMachine.cpp, > line 3308 > [Parent 6521, Gecko_IOThread] WARNING: pipe error: Broken pipe: file > /usr/ports/pobj/firefox-71.0beta8/firefox-71.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, > line 728 > > ktrace -di shows this: > > 99779 firefox NAMI "/usr/lib/libsndio.so.7.0" > 99779 firefox RET open -1 errno 2 No such file or directory
I finally had time to properly dig ainto this, and indeed it tries to dlopen this file in https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_sndio.c#285 - i dont really remember this parts, alex was it here last you worked on the cubeb sndio backend ? this code is coming from https://bugzilla.mozilla.org/show_bug.cgi?id=1575883, which comes from upstream cubeb in https://github.com/kinetiknz/cubeb/commit/9eb4c89535fdf3726900231a804aa35e19b9f93c, which in the end came from https://github.com/kinetiknz/cubeb/pull/539 where jan beich (the freebsd mozilla porter, in cc) moved from linking to libsndio to dlopening at runtime. I have to admit that now that we move towards unveil, dlopen() feels awkward, especially with the version number hardcoded. I dont want to hardcode libsndio.so.7.0 in the unveil config... and i dunno if having /usr/lib/libsndio.so would work. I guess one of the options is to set DISABLE_LIBSNDIO_DLOPEN (cf https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_sndio.c#26) but then one would need to readd sndio to the libs linked (i dont see this done in the build system yet), and i'm not sure this codepath was tested much.. alex, what's your take on this ? Landry
