It appears there are compatibility issues between Ubuntu 12.04 and NVIDIA's proprietary driver which prevent Chrome's GPU accelerated stack from working correctly. Please see

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/988079

I've been told this is landscape case 29165 (at Canonical I assume).

This is my fault, due to the new sandbox that activates on 12.04 LTS.

The crashes, such as https://crash.corp.google.com/reportdetail?reportid=7aca503824aaf835, clearly show that the issue is the Nvidia binary driver trying to create a directory.

Filesystem access is strictly disallowed in the new sandbox!

The good news is that I made a change, which will be in the next Chrome 20 dev channel release (due out today or tomorrow), which denies the filesystem access but allows the process to continue without killing it.

Would you mind reporting back if the imminent dev channel release fixes the issue for you? It'd be much appreciated.

I agree it's not nVidia nor Ubuntu fault since it works in Chrome beta and stable and Firefox, only Chrome dev channel is affected.

It's not fixed in 20.0.1123.2. There are todays crash ids:
eb440d1dbeabc5c2: středa, 2. května 2012 22:06:45
5c084bda6386a003: středa, 2. května 2012 22:06:43
644cd6136b78e139: středa, 2. května 2012 22:06:41
04e688aef82d6aea: středa, 2. května 2012 22:06:40

I'm really sorry it's not fixed. The mkdir() issue is gone but now the crashes correspond to lseek().

We could play whack-a-mole like this forever but there's a better way and I'd be really grateful if anyone experiencing this could follow the following steps and submit the information:

1) Close all instances of Chrome.
2) Launch Chrome from the command line with the following flags:
google-chrome --disable-seccomp-filter-sandbox --gpu-startup-dialog
3) Visit some simple WebGL page, e.g. http://www.ibiblio.org/e-notes/Cryst/NaCl.html -- page should hang at this stage.
4) Find the GPU process PID:
ps auwwwx | grep type=gpu-process
And the PID is the numeric value in the second column (first column is your username)
5) Log the syscalls from the process (replace PID with the value found above):
strace -f -p PID 2> /tmp/strace.log
(NOTE: may need to be root to perform the above)
6) Start the GPU process. Again, replace PID appropriately:
kill -USR1 PID

7) Play with the WebGL demo for a couple of seconds to get some logs and make sure the GPU process is running OK. Don't go for more than a few seconds or the log file may get unneccessarily big.

8) Quit Chrome.

9) Attach the /tmp/strace.log file to this bug.

10) Receive gratitude from me, as well as a very prompt fix :)

Here's the strace.log gathered by running the steps above with Chromium 20.0.1126.0 (Developer Build 135192) on Ubuntu 12.04 with NVIDIA 295.40 drivers and a Quadro FX 380.

strace.log 1.7 MB View Download

First, Chrome updated this morning to 20.0.1123.4 (build 135092)

And here is the strace. I read the "just few seconds" part a bit late, so the ungziped log has 13 MB. :]

Ubuntu 12.04 64bit, nVidia 295.40 (from Ubuntu), GeForce 9600 GT.

strace.log.gz 856 KB Download

Thanks all for the logs. I will land a fix tomorrow that is compatible with the listed syscalls. The next Linux dev channel should work better on 12.04 LTS + GPU.

In the interim, GPU functionality can be restored with the flag --disable-seccomp-filter-sandbox

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=135461

------------------------------------------------------------------------
r135461 | cevans@chromium.org | Fri May 04 15:24:16 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/sandbox_init_linux.cc?r1=135461&r2=135460&pathrev=135461

Add a couple more syscalls for the Nvidia binary driver, based on a real-world
strace from a failing machine.

Also one more Flash policy tweak.

BUG= 125712 
Review URL: https://chromiumcodereview.appspot.com/10383010
------------------------------------------------------------------------

With any luck, fixed in today's dev channel release?
http://googlechromereleases.blogspot.com/2012/05/dev-channel-update_08.html

Unfortunately not. :(

Here are the crashlog ids from this morning:
500cb67d0077f704: středa, 9. května 2012 8:10:33
26b1cd6f87af36e9: středa, 9. května 2012 8:10:31
db5f83c3e9d9df2b: středa, 9. května 2012 8:09:43
c1581c3a445c482d: středa, 9. května 2012 8:09:28
a6331641e283b62a: středa, 9. května 2012 8:09:19

Wanna also another strace?

P.S. nVidia driver updated in Ubuntu repos from 295.40 to 295.49.

Thanks. syscall 0x93 == 147 == sched_get_priority_min

I'd love another strace if it's no trouble. The old strace didn't show this call at all (otherwise we'd have it all working ;-)

Jorge, also looks like the ChromeOS thing you're looking into?

Yes, definitely. Maybe we can get the sched_* calls into the policy and then I'll figure out what else is needed for Chrome OS.

Here is the strace. I Ctrl+C'ed the strace before quiting chrome, but I just grabbed the molecules and rotate them before I closed it. I hope it doesn't matter, the moment it received USR1 signal is recorded.

strace.log 947 KB View Download

Thanks for the new trace. Looks like a new separate issue that was introduced since the last dev channel! Grr!

In fact, the latest dev channel is also broken on my Intel GPU + driver. It's probably broken for everyone.

I'll fix it today.

Ok, a new separate issue, a regression in the latest dev channel.

cc:ing interested parties.

Revision 134791 (http://src.chromium.org/viewvc/chrome?view=rev&revision=134791) introduced a dependency between the GPU process and the crypto subsystem, specifically a usage of HMAC.

For at least the Win and Linux sandboxes, this necessitates warming up the crypto subsystem before locking down the sandbox. So, this may have broken something on Windows too, although we may have gotten "lucky" if our exisiting warming up of the random subsystem happens to warm up the crypto subsystem as a side-effect on Windows (I suspect this may be the case).

Stack trace below illustrates the code stack trace where we enter the crypto subsystem init in a sandboxed context.

Fix immediately forthcoming.


#1  0x00007ff747ebbba0 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x00007ff747eacbea in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#3  0x00007ff74d6faff6 in crypto::(anonymous namespace)::NSPRInitSingleton::NSPRInitSingleton (this=0x7ff754e72c08) at crypto/nss_util.cc:208
#4  0x00007ff74d6fc4b9 in base::DefaultLazyInstanceTraits<crypto::{anonymous}::NSPRInitSingleton>::New(void *) (instance=0x7ff754e72c08)
    at ./base/lazy_instance.h:69
#5  0x00007ff74d6fc3aa in base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSPRInitSingleton>::New(void *) (instance=0x7ff754e72c08)
    at ./base/lazy_instance.h:95
#6  0x00007ff74d6fc2ab in base::LazyInstance<crypto::{anonymous}::NSPRInitSingleton, base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSPRInitSingleton> >::Pointer(void) (this=0x7ff754e72c00) at ./base/lazy_instance.h:159
#7  0x00007ff74d6fc22e in base::LazyInstance<crypto::{anonymous}::NSPRInitSingleton, base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSPRInitSingleton> >::Get(void) (this=0x7ff754e72c00) at ./base/lazy_instance.h:134
#8  0x00007ff74d6fbb26 in crypto::EnsureNSPRInit () at crypto/nss_util.cc:652
#9  0x00007ff74d6fb1db in crypto::(anonymous namespace)::NSSInitSingleton::NSSInitSingleton (this=0x7ff754e72c48) at crypto/nss_util.cc:407
#10 0x00007ff74d6fc590 in base::DefaultLazyInstanceTraits<crypto::{anonymous}::NSSInitSingleton>::New(void *) (instance=0x7ff754e72c48)
---Type <return> to continue, or q <return> to quit---
    at ./base/lazy_instance.h:69
#11 0x00007ff74d6fc3de in base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSSInitSingleton>::New(void *) (instance=0x7ff754e72c48)
    at ./base/lazy_instance.h:95
#12 0x00007ff74d6fc34f in base::LazyInstance<crypto::{anonymous}::NSSInitSingleton, base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSSInitSingleton> >::Pointer(void) (this=0x7ff754e72c40) at ./base/lazy_instance.h:159
#13 0x00007ff74d6fc248 in base::LazyInstance<crypto::{anonymous}::NSSInitSingleton, base::internal::LeakyLazyInstanceTraits<crypto::{anonymous}::NSSInitSingleton> >::Get(void) (this=0x7ff754e72c40) at ./base/lazy_instance.h:134
#14 0x00007ff74d6fbb48 in crypto::EnsureNSSInit () at crypto/nss_util.cc:660
#15 0x00007ff74d6fa061 in crypto::HMAC::Init (this=0x7ff74b69ad38, 
    key=0x7ffff335c490 "\376`=w\302i\207\361\274\303}Z:\016d\345\062\065\333\006L\277\225%|ZD_\326\367F", key_length=32) at crypto/hmac_nss.cc:43
#16 0x00007ff74f847475 in gpu::gles2::MailboxManager::MailboxManager (
    this=0x7ff74b69ad20) at gpu/command_buffer/service/mailbox_manager.cc:20
#17 0x00007ff74e18bcd2 in GpuChannel::GpuChannel (this=0x7ff74b641b40, 
    gpu_channel_manager=0x7ff74b6a76e0, watchdog=0x0, share_group=0x0, 
    client_id=5, software=false) at content/common/gpu/gpu_channel.cc:45
#18 0x00007ff74e131bd7 in GpuChannelManager::OnEstablishChannel (
    this=0x7ff74b6a76e0, client_id=5, share_context=false)
    at content/common/gpu/gpu_channel_manager.cc:100

On trunk, r136384 turns off the seccomp filter sandbox for ChromeOS GPU. I will merge this to M20 once the M20 branch instructions are published. Tagging to make sure I don't forget.

I'll also look at the performance of the NSS for desktop Linux and retarget for M21 if appropriate.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=136400

------------------------------------------------------------------------
r136400 | cevans@chromium.org | Thu May 10 14:59:07 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=136400&r2=136399&pathrev=136400

Warm up the crypto subsystem before entering the GPU sandbox.

BUG= 125712 
Review URL: https://chromiumcodereview.appspot.com/10356114
------------------------------------------------------------------------

One last attempt for M20. If this doesn't work, I'll pull to M21.

Still does not work in 20.0.1132.3 (136408). :(

I'm very sorry, I didn't know there was going to be another dev channel release so the fix did not get merged. I'll merge it over the weekend so it's guaranteed to make the first release early next week.

r136808 disables the GPU sandbox for ChromeOS on M20.

r136809 merges the crypto fix to M20.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=136809

------------------------------------------------------------------------
r136809 | cevans@chromium.org | Sun May 13 13:46:16 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1132/src/content/gpu/gpu_main.cc?r1=136809&r2=136808&pathrev=136809

Merge 136400 - Warm up the crypto subsystem before entering the GPU sandbox.

BUG= 125712 
Review URL: https://chromiumcodereview.appspot.com/10356114

TBR=cevans@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10398003
------------------------------------------------------------------------

WebGL is back! Thanks!

Woohoo! Thanks for all your help.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.