www-client/chromium-28.0.1500.11 and www-client/chromium-28.0.1500.20 fail to load many pages including google maps, get.webgl.org, G+, etc. Also the bookmark manager is borked in both. downgrading to www-client/chromium-27.0.1453.93 brought back usability Reproducible: Always emerge --info Portage 2.2.0_alpha177 (default/linux/amd64/13.0/desktop/kde, gcc-4.7.3, glibc-2.17, 3.9.3-gentoo x86_64) ================================================================= System uname: Linux-3.9.3-gentoo-x86_64-Intel-R-_Core-TM-_i7-3770K_CPU_@_3.50GHz-with-gentoo-2.2 KiB Mem: 32899900 total, 26466308 free KiB Swap: 6291452 total, 6291452 free Timestamp of tree: Fri, 24 May 2013 18:45:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.4, 3.2.4, 3.3.2 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.11.6, 1.12.6, 1.13.2 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo desktop server ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -floop-interchange -floop-strip-mine -floop-block" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -floop-interchange -floop-strip-mine -floop-block" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/desktop /usr/local/portage/server" SYNC="rsync://rsync11.us.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi alsa amd64 amr apache2 audiofile bash-completion berkdb bluray branding bzip2 cairo caps cdaudio cdda cddb cdparanoia cdr cdrdao chm cli consolekit cracklib crypt cups curl cxx dbus declarative designer-plugin djvu dri dts dv dvb dvd dvdr ebook emboss encode exif fam ffmpeg firefox flac fortran gdbm gif gmp gnome gphoto2 gpm graphite gstreamer gtk gtk3 iconv icu ieee1394 imagemagick imap imlib introspection ipv6 jack java jpeg jpeg2k kde kipi kpathsea lame lcms libffi libnotify mad marble midi mmap mmx mng modules mozilla mp3 mp4 mpeg mtp mudflap multilib musicbrainz mythtv ncurses network nls nodrm nptl nsplugin nvidia ofx ogg opencl openexr opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qt3support qt4 quicktime readline rtmp samba sasl scanner sdl semantic-desktop session slp smp sndfile spell sse sse2 ssl startup-notification subversion svg theora threads tiff tk transparency truetype udev udisks unicode upower usb v4l vaapi vcd vdpau vim-syntax vorbis vpx wav wavpack wmf wxwidgets x264 xattr xcomposite xine xinerama xml xscreensaver xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="hda-intel hdsp hpet hrtimer rtctimer seqdummy virmidi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="pdfimport presenter-console presenter-minimizer" LINGUAS="en_US en" NGINX_MODULES_HTTP="autoindex fancyindex fastcgi gzip" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby19" SANE_BACKENDS="epson epson2" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
I am running google-chrome-28.0.1500.20 and all the pages you mentioned load and work fine for me. The bookmark manager works as well. Seems like the problems must be limited to chromium.
(In reply to comment #1) > I am running google-chrome-28.0.1500.20 and all the pages you mentioned load > and work fine for me. The bookmark manager works as well. Seems like the > problems must be limited to chromium. It could be a >=dev-lang/v8-3.18 issue as well as these Chromium ebuilds require it. Don't really know except that they just don't work.
I am running chromium Version 28.0.1500.20 (201172) and all of those pages plus the bookmark manager work fine.
(In reply to Graham Murray from comment #3) > I am running chromium Version 28.0.1500.20 (201172) and all of those pages > plus the bookmark manager work fine. 64 bit? nVidia? same toolchain? must be some difference...
Chromium is actually segfaulting: May 25 22:59:43 sartre kernel: [ 120.665471] Watchdog[2431]: segfault at 0 ip 00007fb2a3b9c16e sp 00007fb28c61b060 error 6 in chrome[7fb2a2e4f000+4855000] May 25 22:59:55 sartre kernel: [ 132.866345] Watchdog[2465]: segfault at 0 ip 00007f3a0c81616e sp 00007f39f5295060 error 6 in chrome[7f3a0bac9000+4855000] May 25 23:00:07 sartre kernel: [ 145.014030] Watchdog[2477]: segfault at 0 ip 00007f4ab523516e sp 00007f4a9dcb4060 error 6 in chrome[7f4ab44e8000+4855000] 100% failure when trying to load get.webgl.org. Previous version - 27.x works fine.
If I set CHROMIUM_FLAGS="--disable-seccomp-filter-sandbox" in /etc/chromium/default the browser appears to work. It was a setting I needed some time ago but was able to do without until now. Seems to be some sort of regression.
Same thing for me. Chromium 28.0.1500.20, nvidia-drivers 319.23, kernel 3.9.3 x64. Without --disable-seccomp-filter-sandbox pages seem to be fully loaded but it takes another ~10 seconds before it draws (until that page tab is white). [14417:14424:0526/091740:ERROR:gpu_watchdog_thread.cc(209)] The GPU process hung. Terminating after 10000 ms.
Same problem here, on nvidia hardware/binary drivers. There is a significant delay before the first webpage is displayed after starting the browser. A lot of Watchdog crashes, as Chris reported. After the initial delay however, the browser seems to work fine. Bookmark manager, Google Maps, everything works. A sample backtrace from the crash: #0 0x00007f12d3ae0ae8 in content::GpuWatchdogThread::DeliberatelyTerminateToRecoverFromHang() [clone .part.8] () #1 0x00007f12d3b4ccd9 in base::MessageLoop::RunTask(base::PendingTask const&) () #2 0x00007f12d3b4e230 in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) () #3 0x00007f12d3b4f2b4 in base::MessageLoop::DoDelayedWork(base::TimeTicks*) () #4 0x00007f12d3b530f6 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #5 0x00007f12d3b52b62 in base::MessageLoop::RunInternal() () #6 0x00007f12d3b697a8 in base::RunLoop::Run() () #7 0x00007f12d3b4c2e5 in base::MessageLoop::Run() () #8 0x00007f12d3b7f341 in base::Thread::ThreadMain() () #9 0x00007f12d3b7a0d9 in base::(anonymous namespace)::ThreadFunc(void*) () #10 0x00007f12d292af3b in start_thread (arg=0x7f12bd178700) at pthread_create.c:308 #11 0x00007f12c65bb50d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Problem still exists with chromium-28.0.1500.36.
(In reply to Chris Smith from comment #9) > Problem still exists with chromium-28.0.1500.36. FYI I've asked upstream sandbox experts for help, https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Ax1d9pw02q0/nKzxY0QqCVYJ Still waiting for their response. It'd be interesting to check what on your system triggers the problem (it's still likely a bug, just trying to figure out how to repro).
(In reply to Paweł Hajdan, Jr. from comment #10) > (In reply to Chris Smith from comment #9) > > Problem still exists with chromium-28.0.1500.36. > > FYI I've asked upstream sandbox experts for help, > https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Ax1d9pw02q0/ > nKzxY0QqCVYJ > > Still waiting for their response. It'd be interesting to check what on your > system triggers the problem (it's still likely a bug, just trying to figure > out how to repro). Wish I knew what it was as well :-) Might be nVidia related. Looks like .45 is available - I'll see if that makes a difference.
I'm currently using chromium-29 on a daily basis, but I don't recall having serious issues with chromium-28. I'm also using latest nvidia-drivers on a 3.9-series (3.9.2) kernel.
Problem still exists with chromium-28.0.1500.45 If I don't pass the "--disable-seccomp-filter-sandbox" flag to Chromium it simply is worthless. Works fine with the flag (like 27.x does without it) but I think there's some sort of security issue involved in setting it.
Just want to add that it may not be the total problem but one is certainly a breakage in OpenGL (WebGL?) - basically any page using it refuses to load properly, such as http://get.webgl.org/ .
(In reply to Mike Gilbert from comment #12) > I'm currently using chromium-29 on a daily basis, but I don't recall having > serious issues with chromium-28. > > I'm also using latest nvidia-drivers on a 3.9-series (3.9.2) kernel. Just installed chromium-29.0.1521.3 to test and I still have the problem. It also needs the flag passed or pages are slow to load (the webgl page eventually loads but it takes some time). Currently using nvidia-drivers-319.23 and gentoo-sources-3.9.5. I have to revert to the 28. series as mongodb doesn't build with v8-3.19.
- If you could run Chrome (not Chromium) dev channel, enable crash reports and give a crash ID, it would be very helpful. - Can you give the content of these two files on your system around the mentioned line numbers? #10 0x00007f12d292af3b in start_thread (arg=0x7f12bd178700) at pthread_create.c:308 #11 0x00007f12c65bb50d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Alternatively, provide a pointer to your exact glibc source.
(In reply to Julien Tinnes from comment #16) > - If you could run Chrome (not Chromium) dev channel, enable crash reports > and give a crash ID, it would be very helpful. > - Can you give the content of these two files on your system around the > mentioned line numbers? > > #10 0x00007f12d292af3b in start_thread (arg=0x7f12bd178700) at > pthread_create.c:308 > #11 0x00007f12c65bb50d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Locate doesn't find a file named pthread_create.c or clone.S on my system. > Alternatively, provide a pointer to your exact glibc source. Running sys-libs/glibc-2.17 in portage (~amd64). Not seeing any errors with www-client/google-chrome-29.0.1541.2_alpha207000 outside of these: ============================= NVIDIA: could not open the device file /dev/nvidia0 (Operation not permitted). NVIDIA: could not open the device file /dev/nvidia0 (Operation not permitted). ============================= # ls -al /dev/nvidia0 crw-rw---- 1 root video 195, 0 Jun 18 15:23 /dev/nvidia0
I had read that thread too fast. This is just the watchdog terminating the task. We still don't know what went wrong. If someone can reproduce with Chrome and submit a crash ID it'll helpful. Meanwhile, --disable-gpu-sandbox would be a better workaround than --disable-seccomp-filter-sandbox.
(In reply to Julien Tinnes from comment #18) > Meanwhile, --disable-gpu-sandbox would be a better workaround than > --disable-seccomp-filter-sandbox. It'd be useful to get confirmation from someone who can repro this bug whether the above workaround works.
(In reply to Paweł Hajdan, Jr. from comment #19) > (In reply to Julien Tinnes from comment #18) > > Meanwhile, --disable-gpu-sandbox would be a better workaround than > > --disable-seccomp-filter-sandbox. > > It'd be useful to get confirmation from someone who can repro this bug > whether the above workaround works. Crazy - after installing Chrome to test with I no longer get the error with Chromium ?? I now get with both the: NVIDIA: could not open the device file /dev/nvidia0 (Operation not permitted). NVIDIA: could not open the device file /dev/nvidia0 (Operation not permitted). errors. But webgl is now working in both without disabling sandboxing.
(In reply to Chris Smith from comment #20) > Crazy - after installing Chrome to test with I no longer get the error with > Chromium ?? Just wondering - what happens when you reboot and try Chromium without using Chrome before? Or does uninstalling Chrome make the error go away (could be a hardcoded path)? This could > I now get with both the: > NVIDIA: could not open the device file /dev/nvidia0 (Operation not > permitted). > NVIDIA: could not open the device file /dev/nvidia0 (Operation not > permitted). I think these can be ignored.
Also see http://forums.gentoo.org/viewtopic-t-961944.html
Created attachment 351832 [details] Stack trace of deadlocked thread Hi, after a couple of tests I now think this bug is only triggered when _not_ using tcmalloc, which is the default case on Gentoo due to known issues (#413637). Enabling/unmasking tcmalloc makes the bug disappear, as does LD_PRELOADing libtcmalloc.so from google-perftools. For an explanation please have a look at the attached stack trace. It shows a (GPU process) thread which, I think, deadlocks during a free() call: glibc's free() implementation tries to open() a file (/proc/sys/vm/overcommit_memory) which is trapped by the sandbox. A "broker process" then matches the file name against a white-list with the help of some STL magic. A hereby (implicitly) created std::string internally calls new() and hence malloc().... There is a clear relation to nvidia binary drivers, however this seems to be a coincidence, since the actual free() call happens inside libX11. And for all I can tell pretty much any call to (glibc's) free() could trigger the deadlock. Anyway, using tcmalloc (in combination with nvidia drivers) is not a good idea as long as the issue mentioned above is unresolved, so the currently best (i.e. least invasive) workaround indeed seems to be "--disable-gpu-sandbox" (which I can confirm to be working as expected). On a side note: /dev/nvidia0 is not on the sandbox' white-list, which explains the error messages ("NVIDIA: could not open the device file...."). Hope this helps.
(In reply to Timo Breitner from comment #23) > For an explanation please have a look at the attached stack trace. It shows > a (GPU process) thread which, I think, deadlocks during a free() call: > glibc's free() implementation tries to open() a file > (/proc/sys/vm/overcommit_memory) which is trapped by the sandbox. A "broker > process" then matches the file name against a white-list with the help of > some STL magic. A hereby (implicitly) created std::string internally calls > new() and hence malloc().... Thank you for a truly excellent analysis. This helps a lot. Upstream is now tracking this issue.
Created attachment 352106 [details, diff] chromium-gpu-sandbox-r0.patch Please test the following patch (successfully applies against chromium-28.0.1500.52). This is intended to be a workaround, not a fix.
I have found that using --reduce-gpu-sandbox also "fixes" the issue in my case. I can't find specifics on the differences between this flag and --disable-gpu-sandbox, though. The only information that I found was that the former (--reduce...) makes the GPU sandbox less strict.
I have applied the r0 patch to chromium-28.0.1500.89, and it eliminates the symptoms of the problem. As Paweł mentioned, this is a workaround, but at least it is better than disabling all GPU sandboxing within Chromium. Thank you, Paweł.
+ 17 Jul 2013; Mike Gilbert <floppym@gentoo.org> + +files/chromium-bug471198.patch, chromium-28.0.1500.71.ebuild, + chromium-28.0.1500.89.ebuild: + Apply upstream fix for bug 471198.
