Chromium too many open files - tabs come a-crashin'

Lately Chromium tabs have been crashing a lot at irregular intervals. It looks like this:

Chrome unresponsive

Like said before, the best way to get a handle on what is causing it is to start chromium in a terminal. Chances are the application is a lot more chatty in the terminal and giving hints as to why its acting up.

What version?

I'm running chromium Version 40.0.2214.111 (64-bit) but I've seen bug reports concerning version 36.0 and up. That bug reports means chromium is running into the limits of the OS regarding allowed open files.

In other words - the more tabs you are using - the more chance there is that the new tabs (and old tabs) will be crashing looking like the sad sad image above.

Y u crash?

Lets dig into this a bit and learn a thing or two. This message would appear whenever a tab crashed.

[13747:13770:0219/150755:ERROR:host_shared_bitmap_manager.cc(144)] Cannot create shared memory buffer
[918:923:0219/150755:FATAL:child_shared_bitmap_manager.cc(55)] Check failed: memory->Map(memory_size).
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED

With some googling this turns out to be the soft limits of open file handles being applied to each chromium tab process. Lets dig. To get the limits of a process you can use prlimit of that process. Choose a chromium tab process id of your liking and hit it with prlimit.

jonasl@jonasl:~$ prlimit --pid 13747
RESOURCE  DESCRIPTION                SOFT    HARD UNITS
...
NOFILE   max number of open files         1024    4096
...

Or if you are really curious about that process, why don't you cd into its /proc/$pid directory hmmm? You can see the limits in a file called limits:

jonasl@jonasl:~$ cat /proc/13747/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             2147483647           2147483647           bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             30772                30772                processes
Max open files            1024                 4096                 files
Max locked memory         1048576              1048576              bytes
Max address space         17179869184          17179869184          bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       30772                30772                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         30                   30
Max realtime priority     65                   65
Max realtime timeout      unlimited            unlimited            us

To get a rough estimate of the number of open files, lets list all for that process and count them by lines:

jonasl@jonasl:~$ lsof -p 13747 | wc -l
1415

Wow imagine that, 1415, way over the soft limit of 1024. Again using prlimit you can raise the number of allowed open files by setting the soft (on the left of the colon, and hard limit on the right of the colon) like so:

jonasl@jonasl:~$ prlimit --pid 13747 --nofile=4096:4096

By now, that tab should have stopped chrashing with the sad sad image. Surf around a bit, and let's again count the numbers of open files:

jonasl@jonasl:~$ lsof -p 13747 | wc -l
1918

Y u crash really hard?

Just out of curiosity then, what happens if we lower the hard limit?

jonasl@jonasl:~$ prlimit --pid 13747 --nofile=1024:1024

Surf some in the tab whose pid you just starved for open file handles. Since the hard limit is now 1024, it will crash all of its siblings and parent process (as opposed to just failing the local tab when enforcing the soft limit) with this funny message

[13747:13771:0219/151309:FATAL:zygote_host_impl_linux.cc(297)] Check failed: 0 == socketpair(AF_UNIX, SOCK_SEQPACKET, 0, raw_socks). : Too many open files
Aborted (core dumped)

Three fixes for this

The fastest way to increase this is to close down chromium and up the limit with ulimit in the terminal before you start it again. This way you can see if this was your root issue before making the fix permanent. Hit:

ulimit -n 4096
chromium

in a terminal. This will set the number of allowed open files per process to 4096 instead of the default 1024.

jonasl@jonasl:~$ prlimit --pid 15691
RESOURCE  DESCRIPTION                SOFT    HARD UNITS
...
NOFILE   max number of open files         4096    4096
...

Three ways moving forward from here. You can apply this only to chromium by either creating a script on your path setting ulimit before launching chromium - or you can editing the launcher script of chromium itself (located in /usr/bin/chromium on arch linux) adding the ulimit fix before chromium itself is launched:

jonasl@jonasl:~$ which chromium
/usr/bin/chromium

jonasl@jonasl:~$ sudo vim /usr/bin/chromium

Third and most impressive solution is if you are running on a desktop you can impress your friends with cranking up the number of allowed open files to whatever your liking screaming "I don't care". The main reason for having a limit is memory consumption. And you are probably not running chromium on your paltry embedded device.

We're all to blame for this

So in all it's not just chromiums fault, it seems it has gotten more file resource hungry, but its also the default setting of linux.