When updating Firefox I came across a SANDBOX ACCESS VIOLATION when building with pgo. Steps to reproduce: 1. Build Firefox with USE="pgo" # /var/tmp/notmpfs/portage/www-client/firefox-110.0/temp/sandbox.log VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /dev/snd/seq A: /dev/snd/seq R: /dev/snd/seq C: /var/tmp/notmpfs/portage/www-client/firefox-110.0/work/firefox_build/instrumented/dist/firefox/firefox http://localhost:8888/index.html -profile /var/tmp/notmpfs/portage/www-client/firefox-110.0/temp/tmpxxeq4vfh F: open_wr S: deny P: /dev/snd/seq A: /dev/snd/seq R: /dev/snd/seq C: /var/tmp/notmpfs/portage/www-client/firefox-110.0/work/firefox_build/instrumented/dist/firefox/firefox http://localhost:8888/index.html -profile /var/tmp/notmpfs/portage/www-client/firefox-110.0/temp/tmpxxeq4vfh
Created attachment 853522 [details] emerge --info output
Could you upload the full build.log please? You can use "xz -9" to compress it.
Created attachment 853888 [details] full build.log
So I was able to build firefox with your use flags on a normal glibc system. Then I spent a day setting up a musl container... just to realize pgo is use.masked for firefox in musl. So by that definition pgo won't work with musl. However your error doesn't seem to be related to musl, but I'd rather blame -dbus and your system overall instead. If you want to try, add: addpredict /dev/snd to line 552 in the ebuild. To clarify, you want to edit this: # May need a wider addpredict when using wayland+pgo. addpredict /dev/dri into this: # May need a wider addpredict when using wayland+pgo. addpredict /dev/dri addpredict /dev/snd (Again, I was able to compile firefox with -dbus +pgo +lto so just guessing here)
I've just compiled Firefox with your suggested fix with both PGO & clang on musl which are masked, and it built successfully, so is there any reason for it to still be masked? I've had both unmasked for 1–2 months without even noticing until this issue came up and like you said it doesn't seem related to musl, and Alpine also seems to use PGO (not sure about clang) when building Firefox on amd64 (https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n614). Thank you very much for your help and suggested fix and sorry if I wasted any of your time.
The issue was/is that building with clang[-default-libcxx] (or otherwise not passing -stdlib=libc++ or whatever it is) would fail. I haven't verified that now works.
(In reply to sqrtd from comment #5) > I've just compiled Firefox with your suggested fix with both PGO & clang on > musl which are masked, and it built successfully, so is there any reason for > it to still be masked? I've had both unmasked for 1–2 months without even > noticing until this issue came up and like you said it doesn't seem related > to musl, and Alpine also seems to use PGO (not sure about clang) when > building Firefox on amd64 > (https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n614). > > Thank you very much for your help and suggested fix and sorry if I wasted > any of your time. Just for the record, they use also clang/clang++ to compile: https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n639
While this bug may not be fixed (relate to -dbus), pgo is now available on musl with commit d48fc6e32f86ef142c73c7c546d23d607334319e
Our "current" versions should have pretty wide sandbox relaxation when using pgo. 115esr may not work, but it's probably having its last version bump this week so I'm not going to spend time relaxing the sandbox paths there. 128esr and 130rapid should be okay, even in musl.
