Created attachment 477174 [details] full output running chromium When starting chromium i get the following error: [1:1:0618/220214.398445:FATAL:sandbox_linux.cc(180)] Check failed: sandbox::Credentials::MoveToNewUserNS(). after which chromium exits. I can run chromium with the --disable-namespace-sandbox flag. when running chromium with the --disable-namespace-sandbox flag i get the following error: '[13091:13091:0618/215820.299225:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process. libpng warning: iCCP: known incorrect sRGB profile after which chromium runs fine. google chrome also runs fine. I think the problem might have stated after updating to sys-devel/gcc-5.4.0-r3 and have rebuild world hopping it will help.
Created attachment 477176 [details] emerge --info www-client/chromium
Created attachment 477178 [details] emerge --info www-client/google-chrome
Created attachment 477180 [details] chrome://gpu (chromium)
Created attachment 477182 [details] chrome://gpu/ (google chrome)
Created attachment 477186 [details] chrome://gpu (chromium)
Created attachment 477188 [details] chrome://gpu/ (google chrome)
I am not experiencing any issues. If you figure out what you changed on your system to break this, let us know.
Can you suggest what else i can try? I have tried a few different versions of chromian. Also is there a way to get a more detailed output to get a better idea of the problem.
Likely problem areas: - kernel options - glibc - linux-headers
(In reply to Mike Gilbert from comment #10) > Likely problem areas: > > - kernel options > - glibc > - linux-headers If it was to do with kernel options or glibc would google-chrome not exhibit the same problems. With the kernel-headers i have had chromium working with the same headers.
comparing the chrome and chromium chrome://gpu the main difference i see is that chromium is using the mesa driver and google-chrome is using the ES driver. What is the ES driver that google chrome is using?
Sent request for upstream help at https://groups.google.com/a/chromium.org/d/msg/security-dev/eYCu_Y9HjSY/WuZ1SHBMAwAJ . Since it's not clear yet what info we need, I'd prefer to keep this bug open.
Ben, could you post strace logs?
Created attachment 478274 [details] strace
I am still having the same problem with 60.0.3112.78
Could you run the browser with --v=1 command-line flag and report back what it prints? (attach everything if in doubt) This has been advised by one of the upstream developers.
Created attachment 488302 [details] output with --v=1 I have attached the output will --v=1 but i do not see anything that was not in the previous output dump
Thank you. Yeah, looks like nothing new there. While I continue to ping upstream developers for advice, could you please file an upstream bug report (https://crbug.com/newbug) and post the link to it here?
It's because of Gentoo bug #622700 Downgrade your samba version to <4.5 until Gentoo can fix the Samba package to not automatically enable lttng debug support.
Downgrading samba as Rick Harris suggested fixes the problem. seams the problem is with samba.
This could be quite fascinating. What would be the steps to reproduce? Just install >=samba-4.5? Consider specifying a specific version. Make sure it uses lttng? Since I don't have samba _running_, do I have to start the daemon for the issue to repro? If so, what config? Finally, what confuses me is that it was mentioned earlier Chrome is not affected. Please explain more, since if samba caused this, I'd understand both should hit the same issue.
Not entirely sure but i had =net-fs/samba-4.5.10 and =dev-util/lttng-ust-2.7.1., Samba was not running, but had problems opening chromimum. after downgrading samba, chromium worked (I did not recompile chromium) Could i be to do with difference how (or if) chromium and chrome link to samba?
(In reply to Ben Sagal from comment #23) > Not entirely sure but i had =net-fs/samba-4.5.10 and > =dev-util/lttng-ust-2.7.1., Samba was not running, but had problems opening > chromimum. I tried this, but couldn't reproduce. > after downgrading samba, chromium worked (I did not recompile chromium) > > Could i be to do with difference how (or if) chromium and chrome link to > samba? Neither chromium nor chrome should link to samba. Please confirm whether Chrome is affected by this issue. If needed, check if upgrading samba back re-creates the issue. Try to come up with a list of steps someone else would be able to repro.
(In reply to Paweł Hajdan, Jr. from comment #24) > (In reply to Ben Sagal from comment #23) > > I tried this, but couldn't reproduce. > > Neither chromium nor chrome should link to samba. media-video/ffmpeg is a direct dependency of chromium via it's default enabled '+system-ffmpeg' useflag. On a 'samba' USE enabled system, chromium will indirectly link to samba via media-video/ffmpeg[samba]. Snippet from 'ldd -v /usr/lib64/chromium-browser/chrome': /usr/lib64/libavformat.so.57: libz.so.1 (ZLIB_1.2.0.2) => /lib64/libz.so.1 libsmbclient.so.0 (SMBCLIENT_0.1.0) => /usr/lib64/libsmbclient.so.0 > If needed, check if upgrading samba back re-creates the issue. Try to come > up with a list of steps someone else would be able to repro. Steps to reproduce: 1. emerge lttng-ust 2. emerge >=samba-4.5 3. emerge ffmpeg[samba] 4. Run Chromium and watch it fail
Created attachment 490214 [details] emerge --info chromium Actually needed samba for something the other day so I added it to my make.conf. I was unable to launch Chromium after running emerge -uDNav @world, (which included media-video/ffmpeg +samba) Let me know if there's any other information I can provide. Note: This started happening before I emerged chromium with component-build and debugsyms (package.env).
I reproduced this - thanks to excellent steps from Rick Harris. That's the top-notch Gentoo community I really appreciate. :) For everyone experiencing this issue: based on bug #622700 , emerge --sync and re-emerging samba should fix this. I'd like to update chromium dependencies for this, but I'd need a samba version bump (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6317e7c12e21da53904f0670ce1ffa9b8eecefd4 updated ebuilds in place, which surprises me, as it is behavior change and users who have the package should automatically get the fix); CC samba@ team to advise. Here are some more details on what happens when lttng gets loaded into the address space. liblttng-ust/lttng-ust-comm.c uses __attribute__((constructor)) lttng_ust_init which creates threads running ust_listener_thread upon loading the library. I couldn't find a way to disable this behavior, and it really messes up chromium sandbox: [1:1:0823/101214.476138:FATAL:zygote_main_linux.cc(482)] Check failed: sandbox::ThreadHelpers::IsSingleThreaded(). #0 0x7ffff7676b67 base::debug::StackTrace::StackTrace() #1 0x7ffff7674936 base::debug::StackTrace::StackTrace() #2 0x7ffff76ed60e logging::LogMessage::~LogMessage() #3 0x7fffef0690b2 content::EnterLayerOneSandbox() #4 0x7fffef06978d content::ZygoteMain() #5 0x7ffff0f83c15 content::RunZygote() #6 0x7ffff0f84041 content::RunNamedProcessTypeMain() #7 0x7ffff0f84f02 content::ContentMainRunnerImpl::Run() #8 0x7ffff0f827d8 content::ContentServiceManagerMainDelegate::RunEmbedderProcess() #9 0x7ffff7e6f149 service_manager::Main() #10 0x7ffff0f83656 content::ContentMain() #11 0x55555619308c ChromeMain #12 0x555556192f81 main #13 0x7fffd5b4172c __libc_start_main #14 0x555556192e49 _start Thread 3 (Thread 0x7fffbf5e4700 (LWP 31023)): #0 0x00007fffd5c0a699 in syscall () from /lib64/libc.so.6 #1 0x00007fffc35082c8 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, op=0, uaddr=<optimized out>) at /usr/include/urcu/futex.h:65 #2 futex_async (op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0, uaddr=<optimized out>) at /usr/include/urcu/futex.h:88 #3 wait_for_sessiond (sock_info=0x7fffc3754040 <local_apps>) at lttng-ust-comm.c:1170 #4 ust_listener_thread (arg=0x7fffc3754040 <local_apps>) at lttng-ust-comm.c:1222 #5 0x00007ffff7bc22f0 in start_thread () from /lib64/libpthread.so.0 #6 0x00007fffd5c0ef7d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fffbfde5700 (LWP 31022)): ---Type <return> to continue, or q <return> to quit--- #0 0x00007fffd5c0a699 in syscall () from /lib64/libc.so.6 #1 0x00007fffc35082c8 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, op=0, uaddr=<optimized out>) at /usr/include/urcu/futex.h:65 #2 futex_async (op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0, uaddr=<optimized out>) at /usr/include/urcu/futex.h:88 #3 wait_for_sessiond (sock_info=0x7fffc3756080 <global_apps>) at lttng-ust-comm.c:1170 #4 ust_listener_thread (arg=0x7fffc3756080 <global_apps>) at lttng-ust-comm.c:1222 #5 0x00007ffff7bc22f0 in start_thread () from /lib64/libpthread.so.0 #6 0x00007fffd5c0ef7d in clone () from /lib64/libc.so.6
(In reply to Paweł Hajdan, Jr. from comment #27) > I reproduced this - thanks to excellent steps from Rick Harris. That's the > top-notch Gentoo community I really appreciate. :) > > For everyone experiencing this issue: based on bug #622700 , emerge --sync > and re-emerging samba should fix this. > > I'd like to update chromium dependencies for this, but I'd need a samba > version bump > (https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=6317e7c12e21da53904f0670ce1ffa9b8eecefd4 updated ebuilds in place, which > surprises me, as it is behavior change and users who have the package should > automatically get the fix); CC samba@ team to advise. > > Here are some more details on what happens when lttng gets loaded into the > address space. liblttng-ust/lttng-ust-comm.c uses > __attribute__((constructor)) lttng_ust_init which creates threads running > ust_listener_thread upon loading the library. I couldn't find a way to > disable this behavior, and it really messes up chromium sandbox: > > [1:1:0823/101214.476138:FATAL:zygote_main_linux.cc(482)] Check failed: > sandbox::ThreadHelpers::IsSingleThreaded(). > #0 0x7ffff7676b67 base::debug::StackTrace::StackTrace() > #1 0x7ffff7674936 base::debug::StackTrace::StackTrace() > #2 0x7ffff76ed60e logging::LogMessage::~LogMessage() > #3 0x7fffef0690b2 content::EnterLayerOneSandbox() > #4 0x7fffef06978d content::ZygoteMain() > #5 0x7ffff0f83c15 content::RunZygote() > #6 0x7ffff0f84041 content::RunNamedProcessTypeMain() > #7 0x7ffff0f84f02 content::ContentMainRunnerImpl::Run() > #8 0x7ffff0f827d8 > content::ContentServiceManagerMainDelegate::RunEmbedderProcess() > #9 0x7ffff7e6f149 service_manager::Main() > #10 0x7ffff0f83656 content::ContentMain() > #11 0x55555619308c ChromeMain > #12 0x555556192f81 main > #13 0x7fffd5b4172c __libc_start_main > #14 0x555556192e49 _start > > Thread 3 (Thread 0x7fffbf5e4700 (LWP 31023)): > #0 0x00007fffd5c0a699 in syscall () from /lib64/libc.so.6 > #1 0x00007fffc35082c8 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, > op=0, uaddr=<optimized out>) > at /usr/include/urcu/futex.h:65 > #2 futex_async (op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0, > uaddr=<optimized out>) > at /usr/include/urcu/futex.h:88 > #3 wait_for_sessiond (sock_info=0x7fffc3754040 <local_apps>) at > lttng-ust-comm.c:1170 > #4 ust_listener_thread (arg=0x7fffc3754040 <local_apps>) at > lttng-ust-comm.c:1222 > #5 0x00007ffff7bc22f0 in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fffd5c0ef7d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 0x7fffbfde5700 (LWP 31022)): > ---Type <return> to continue, or q <return> to quit--- > #0 0x00007fffd5c0a699 in syscall () from /lib64/libc.so.6 > #1 0x00007fffc35082c8 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, > op=0, uaddr=<optimized out>) > at /usr/include/urcu/futex.h:65 > #2 futex_async (op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0, > uaddr=<optimized out>) > at /usr/include/urcu/futex.h:88 > #3 wait_for_sessiond (sock_info=0x7fffc3756080 <global_apps>) at > lttng-ust-comm.c:1170 > #4 ust_listener_thread (arg=0x7fffc3756080 <global_apps>) at > lttng-ust-comm.c:1222 > #5 0x00007ffff7bc22f0 in start_thread () from /lib64/libpthread.so.0 > #6 0x00007fffd5c0ef7d in clone () from /lib64/libc.so.6 Can confirm re-emerging samba works on my system (4.12.8-gentoo).
Updated dependencies for M61+: https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromium?id=9dd2a28b1140fbd79872aeac003d8a65738d3e89 I'm not touching stable ebuilds yet. I'll close the bug when the fix makes it to stable.
No problem, happy to help. Not wanting to pollute this bug with waffle but it's probably worthy enough to note here to be wary of this lttng-ust library in future also. This is not the last you will see it causing trouble. Not only does lttng-ust break Chromium's sandbox, it also breaks portage's emerge sandbox. Any executable invoked during the emerge process, that also links to a library that may link to lttng-ust, will break the emerge and cause the portage sandbox'ed build to hang indefinitely (see bug #624068 for an example of that). It just happens to be Samba this time around, but I've seen it happen with other packages not in main portage tree. More and more packages are starting to lib link to lttng-ust as a debugger :( Cheers :)
This also affects dev-qt/qtwebengine-5.9.5 as used by KMail. I would suggest to adjust the summary to include the most prominent error message: "Check failed: sandbox::Credentials::MoveToNewUserNS()."
(In reply to Dennis Schridde from comment #31) > This also affects dev-qt/qtwebengine-5.9.5 as used by KMail. But re-emerging samba does not help. * dev-util/lttng-ust is not installed * net-fs/samba-4.8.1 * Qt 5.9.5 * KDE Frameworks 5.45.0 * KDE Apps 18.04.0 * KDE Plasma 5.12.5 * Linux 4.16.7-gentoo * Due to bug #654216 I currently do not have www-client/chromium installed
The affected Chromium versions have been stable for a while now.
> This also affects dev-qt/qtwebengine-5.9.5 as used by KMail. If someone comes here looking for similar bug with KMail, then you read read this thread https://forums.gentoo.org/viewtopic-p-8224754.html?sid=d55e556ca163118f7cf471e9a18659cb#8224754
(In reply to Eugene Bright from comment #34) > > This also affects dev-qt/qtwebengine-5.9.5 as used by KMail. > > If someone comes here looking for similar bug with KMail, then you read read > this thread > https://forums.gentoo.org/viewtopic-p-8224754. > html?sid=d55e556ca163118f7cf471e9a18659cb#8224754 Thanks, Eugene! Is there a bug report for this issue?
