Constant "Aw, snap!" in Chromium on musl

[Logarithmus]

System

• package: chromium
• affected package(s) including the version: latest version of chromium from the tier 1 repo

Expected behavior

Normal operation

Actual behavior

Aw, snap! Error 256 appears and the tab dies.

Steps to reproduce the behavior

Open Chromium and browse the Internet for some time, especially JS-heavy websites like YouTube or Facebook.

[fosslinux]

Can reproduce. Not consistently though. Likely relation to #29105.

[github-actions[bot]]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[fosslinux]

not fixed

[github-actions[bot]]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[Logarithmus]

Bump

[ohoes]

Seems to have to do with the fact that sandboxed chromium uses features that are missing in musl. If you run chromium with "--no-sandbox" option, i.e. without sandbox mode, then the problem is not present. I can't believe that after all these years this still hasn't been fixed. Very disappointing.

[Duncaen]

Its not that simple, --no-sandbox has a bunch of implications other than the simple filtering of system calls, the issues are most likely related to multi threading and locks/mutexes, --no-sandbox makes chromium basically single threaded.

[ohoes]

Its not that simple, --no-sandbox has a bunch of implications other than the simple filtering of system calls, the issues are most likely related to multi threading and locks/mutexes, --no-sandbox makes chromium basically single threaded.

Still, running without sandbox is the only workaround (that I know of), though. Perhaps it would be useful to add it to the package. Without that argument, Chromium is practically unusable on musl.

[Duncaen]

You should not be using chromium without the sandbox though, yes its unusable.

[klardotsh]

Chromium here is so far beyond broken as to be comical, and this seems to be a somewhat recent regression.

• Constant tab deaths as described in OP
• Constant infinite-loading-spinner states when navigating between pages
• Generally hangs when trying to kill tabs stuck in ^ state
• Occasional full browser locks

This happens with or without sandbox flags, with GTK 3 or 4 (set by CLI flags), with X11 or Wayland Ozone hints, and seemingly no matter what.

Unfortunately some of the above appears to be Blink related and not Chromium-specific, as the same freezing happens with Qutebrowser. Functionally, this means I have to use a glibc-based Distrobox container to run Chromium-ish browsers for that 5-10% of the internet too lazy to check their work in Firefox, because nothing Chromium-based currently works on my musl-based install.

[ohoes]

Chromium here is so far beyond broken as to be comical, and this seems to be a somewhat recent regression.

* Constant tab deaths as described in OP

* Constant infinite-loading-spinner states when navigating between pages

* Generally hangs when trying to kill tabs stuck in ^ state

* Occasional full browser locks

This happens with or without sandbox flags, with GTK 3 or 4 (set by CLI flags), with X11 or Wayland Ozone hints, and seemingly no matter what.

Unfortunately some of the above appears to be Blink related and not Chromium-specific, as the same freezing happens with Qutebrowser. Functionally, this means I have to use a glibc-based Distrobox container to run Chromium-ish browsers for that 5-10% of the internet too lazy to check their work in Firefox, because nothing Chromium-based currently works on my musl-based install.

Actually, I now use chromium with jitless js flags, and it works almost flawlessly (for me) crazy enough. Took me a darn long time to get this working on musl. I found it at the ungoogled chromium repo. Let me know if it works for you, too. https://github.com/DAINRA/ungoogled-chromium-void?tab=readme-ov-file#musl-crashes-mitigation)

[klardotsh]

While --jitless has been helping me use Chromium and Qutebrowser when necessary, I've finally run into an actual dealbreaker with that: --jitless disables WebAssembly, which means that an increasing amount of the internet breaks with it. For example (what made me go down the research rabbit hole today on this flag): Facebook Messenger end-to-end encryption is implemented this way. I just can't access my DMs on that platform in any V8-based browser right now, outright. With Firefox becoming less and less optimal for my uses as they layer on AI and adtech garbage, this is becoming an acute issue.

Further, the V8 blog talks extensively about the performance implications of this flag. The flag is a bad idea in environments that don't need it (iOS seems to come up as one such place in other tickets), IMO.

We should probably look through the patchset Alpine applies and see what we're missing, and if any of the missing patches can fix this issue. I'm amazed there's not more comments here, maybe the set of us Musl users is much smaller than I thought?

[Johnnynator]

Microsoft upstreamed a wasm interpreter to chromium (v8_enable_drumbrake), enabling might help to have jitless working without breaking websites. Chromium 129 should be the first version shipping with this code (but disabled, no idea how broken or useful it might be) but worth a shot to look into.

[Johnnynator]

--js-flags="--jitless --wasm_jitless" on 129 gives a working wasm interpreter. Worked fine on some random test websites, is kinda as slow as the js interpreter.

52286