Linux: Yet Another Google Chrome “Aw, snap” solved.

“Aw, snap” in Google Chrome happens when a process (or thread?) involved with Chrome dies unexpectedly. I got quite a few of those, and learned to live with them for about a year, as I couldn’t figure out what caused them. It was clear that it had to do with Adobe Flash somehow, and that it happened in certain sites, in certain situations. For example, Facebook’s messenger page always crashed. For those pages, I diverted to using the slower Firefox.

Adobe Flash continued to work fine in many other sites however.

This problem started after upgrading the kernel on Fedora Core 12 to a v3.12.20 I’ve compiled myself. Google Chrome is a 27.0.1453.93. All revisions can be upgraded in theory, but given all kinds of dependencies, the only way was to upgrade Linux completely. And I wasn’t ready to mess up a stable computer that does a lot of other things just to get rid of an annoying issue with Chrome.

For some reason, I couldn’t get a crash report from Chrome. I managed to enable reporting, but no report was ever generated.

The clue was there all along. These log entries kept appearing in /var/log/messages every time I launched Chrome:

Aug  7 13:01:15 kernel: audit_printk_skb: 16 callbacks suppressed
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.119:56738): ses=1 pid=15006 comm="chrome" sig=0 syscall=20 compat=1 ip=0xf2df8430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.297:56739): ses=1 pid=15030 comm="chrome" sig=0 syscall=5 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.297:56740): ses=1 pid=15030 comm="chrome" sig=0 syscall=33 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.297:56741): ses=1 pid=15030 comm="chrome" sig=0 syscall=5 compat=1 ip=0xf2d98044 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.297:56742): ses=1 pid=15030 comm="chrome" sig=0 syscall=85 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.298:56743): ses=1 pid=15030 comm="chrome" sig=0 syscall=195 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.298:56744): ses=1 pid=15030 comm="chrome" sig=0 syscall=195 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.298:56745): ses=1 pid=15030 comm="chrome" sig=0 syscall=195 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.298:56746): ses=1 pid=15030 comm="chrome" sig=0 syscall=195 compat=1 ip=0xf2d80430 code=0x50000
Aug  7 13:01:15 kernel: type=1326 audit(1438941675.298:56747): ses=1 pid=15030 comm="chrome" sig=0 syscall=195 compat=1 ip=0xf2d80430 code=0x50000

Googling a bit on “audit chrome type=1326″ I found this page making the connection with seccomp, and this page suggesting the solution in the comments.

Now, that made sense. Seccomp is a mechanism in Linux to cut off a process irreversibly from the outer world, so it can only read() and write() to already open file descriptors (supposedly going to pipes) or to terminate gracefully with exit(). Or use sigreturn(). It’s a neat security mechanism for not-so-trusted code that only needs to compute stuff. Codecs, for example. And Google Chrome uses this mechanism with Flash.

Maybe this explains why no crash report was generated: The process that crashed was jailed, so it couldn’t open the crash report file.

To fix this, I invoke Google Chrome with

$ google-chrome --disable-seccomp-filter-sandbox

And no more “Aw snaps”.

As the title implies, this solved my problem on a very certain machine with a very certain setting. There are millions of other reasons.