Chromium prints the following error in the console at startup infinitely: ERROR:network_service_instance_impl.cc(539)] Network service crashed, restarting service. Chromium window then shows up (error is still showing as long as Chromium runs), but it shows "Aw snap" error with Error code: 11. It's not possible to load any website. It is possible to run Chromium fine if I build it with -suid and then start with --no-sandbox. Reproducible: Always Steps to Reproduce: Run chromium. Actual Results: Fails to run correctly. Expected Results: Should run fine. I suppose the issue may be related to my kernel configuration, but the checks run during emerging the ebuild are successful.
Created attachment 849433 [details] kernel config
Created attachment 849435 [details] emerge --info
I'm having this exact same problem. Without posting all my emerge --info and local kernel configs (which I'm happy to do, but the details below may explain the issue without those details), here's what I did discover after a bunch of testing and recompiling compiler stacks and Chromium: When I did my weekly emerge -u, GCC 11.3 got upgraded (to 12.2.x), as did llvm and clang, from 15.0.6 to 15.0.7. As part of that emerge in the Clang stack, portage wanted me to etc-update /etc/clang/gentoo-common.cfg; the change was to include /etc/clang/gentoo-hardened.cfg. All Chromiums I built after that hardened .cfg inclusion successfully build, but exhibit this behavior at runtime, with the console output reported over at GitHub (regarding "network_service_instance_impl.cc") being observed. If I remove that line from /etc/clang/gentoo-common.cfg (but keep the 15.0.7 llvm+clang and gcc 12.2 compiler stack), chromium-109.0.5414.119 builds and runs just fine.
What we need now is to figure out which flag in gentoo-hardened.cfg causes it. My complete guess is -fstack-clash-protection or the libcxx one. Please comment them out individually to determine which. Ccache should help a tonne.
(In reply to Sam James from comment #4) > What we need now is to figure out which flag in gentoo-hardened.cfg causes > it. My complete guess is -fstack-clash-protection or the libcxx one. Please > comment them out individually to determine which. Ccache should help a tonne. I had the same problem with Chromium, and commenting out ONLY -fstack-clash-protection in gentoo-hardened.cfg seems to have fixed it.
(In reply to Tiernan Hubble from comment #5) > (In reply to Sam James from comment #4) > > What we need now is to figure out which flag in gentoo-hardened.cfg causes > > it. My complete guess is -fstack-clash-protection or the libcxx one. Please > > comment them out individually to determine which. Ccache should help a tonne. > > I had the same problem with Chromium, and commenting out ONLY > -fstack-clash-protection in gentoo-hardened.cfg seems to have fixed it. Thanks for that! Given we had bug 865339 too, I now suspect Clang's implementation of it is broken.
(In reply to Tiernan Hubble from comment #5) > I had the same problem with Chromium, and commenting out ONLY > -fstack-clash-protection in gentoo-hardened.cfg seems to have fixed it. My Chromium build finished overnight (I need a new machine! ;-) and can confirm that _just_ removing the stack clash protection flag solves this specific problem with Chromium.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee5aadc4bb62d5479d8bc31fa06eb2e5a1bbacc3 commit ee5aadc4bb62d5479d8bc31fa06eb2e5a1bbacc3 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-03 07:10:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-03 07:10:41 +0000 sys-devel/clang-common: drop -fstack-clash-protection There's very likely some Clang miscompilation occurring with -fstack-clash-protection, GCC's implementation is fine. Both qtcore and chromium have been reported to misbehave at runtime when built with Clang's. Drop it for now until we can look into it more or Clang gets fixed. Closes: https://bugs.gentoo.org/865339 Closes: https://bugs.gentoo.org/892537 Signed-off-by: Sam James <sam@gentoo.org> .../{clang-common-15.0.7-r1.ebuild => clang-common-15.0.7-r2.ebuild} | 3 ++- ...pre20230107-r1.ebuild => clang-common-16.0.0_pre20230107-r2.ebuild} | 3 ++- ....0_pre20230127.ebuild => clang-common-16.0.0_pre20230127-r1.ebuild} | 3 ++- ...lang-common-16.0.0_rc1.ebuild => clang-common-16.0.0_rc1-r1.ebuild} | 3 ++- 4 files changed, 8 insertions(+), 4 deletions(-)
Thanks for the help! Unfortunately, both of the cases of miscompilation w/ -fstack-clash-protection are absolutely huge (qtcore & chromium) which doesn't make it easy for us to send anything meaningful upstream. If someone is bored and building their system with Clang, doing so with -fstack-clash-protection and reporting any test failures which don't happen without it would be helpful, as we could then hopefully find a much smaller test case.
OK, it looks like there were actually two issues mixed. Because now I'm back to my problem that I had for some time (hence the kernel config attached). If I build Chromium with -suid and try to run it, I get: [17893:17893:0204/114306.878714:FATAL:zygote_host_impl_linux.cc(127)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox. After appending --no-sandbox, it runs fine. When built with suid, it also runs fine, but I shouldn't need it because I have all the kernel features Portage recommends, so it must be missing something.
