Can you provide a crash ID?
from about:crashes 

Crash reporting is not available in Chromium.  I'm currently doing a Debug build of r265382.  Running the Release build of r265382 with a clean profile didn't kill it immediately.  Eventually in gdb:

> gdb /usr/lib/chromium/chromium
[...]
(gdb) set args --enable-logging --v=1 --user-data-dir=/home/jashank/.config/chromium-dev --debug --single-process --enable-print-preview --ppapi-flash-path=/usr/lib/PepperFlash/libpepflashplayer.so --ppapi-flash-version=13.0.0.182
(gdb) run
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdb251700 (LWP 14637)]
0x0000555556d19375 in ?? ()

The crashed thread's stack is intact, but has no symbols down to about frame 26, where it's in -lpthread.

With my usual profile, I get

[25693:25693:0426/101738:FATAL:render_frame_host_manager.cc(974)] Check failed: !ChildProcessSecurityPolicyImpl::GetInstance()->HasWebUIBindings( render_view_host->GetProcess()->GetID()). 
Program received signal SIGABRT, Aborted.
0x00007ffff1502389 in raise () from /usr/lib/libc.so.6

but that looks like a separate bug related to --single-process.

On a hunch, I tried disabling the Google Cast extension (boadgeojelhgndaghljhdicfkmllpafd).  No change.

I've tried without PPAPI Flash and without libpdf.  No change.

Some interesting observations at this point: with a Debug build, I can crash the browser just as consistently.  chrome://tracing provides no useful hints.  I have a simple shell construct that prints out the number of open file descriptors every second, and the value often lies in the high 800-900s.

Given the default resource limits on this system (a soft-maximum of 1024 open file descriptors per process; a hard maximum of 4096), this strikes me as being the reason tabs are regularly shot down by SIGABRTs.

This looks like a bad shared memory (and, thus, file descriptor) leak in shared_memory_posix.cc.  I don't feel that the "just raise your system's FD limit" that many other related issues list is a valid solution.

Related:  issue 158230  comment 10,   issue 226319  ,   issue 253036  ,  issue 269936 ,  issue 359181 ,  issue 351897 ,  issue 357454 .

(I also don't think that implementing shm as mmap(3)'d files on a tmpfs is a particularly sensible solution, either, especially for applications like Chromium whose operation relies on cheap and functional shm, but it's certainly obvious that no-one took that into account when designing Linux's shared memory implementation.)

edit: typo

Also, yes, having actually thought about it, this _is_ a regression.  Worked before 33.0.1750.152 and 34.0.1847.116 (although I was using the "official" Arch Linux binaries, not compiling it myself).

I'm getting this issue as well on Version 36.0.1964.2 dev.  Tabs crash on load or on scroll after Chrome has been running for a while(~24 hours).  The console log shows 

[10061:10089:0502/095014:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
[10061:10089:0502/095014:ERROR:raw_channel_posix.cc(114)] read: Connection reset by peer
[10061:10089:0502/095014:ERROR:channel.cc(292)] RawChannel fatal error (type 1)

On the crashed tab(Aw Snap, etc just as jashank noted.  

This should be flagged as a critical regression (still broken as of r270407).  I haven't come up with a good solution other than prlimit'ing Chromium as it starts.

I'm seeing aw snap tab crashes on a wide variety of my regular tabs today, running google-chrome Version 36.0.1985.18 beta.  E.g.

 [24082:24122:0526/084141:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
 Parent failed to complete crash dump.
 [24082:24122:0526/084141:ERROR:crash_handler_host_linux.cc(212)] Received death signal message with the wrong size; msg.msg_controllen:56 msg.msg_flags:8 kCrashContextSize:1584 kControlMsgSize:56
 [24082:24122:0526/084141:ERROR:shared_memory_posix.cc(231)] Creating shared memory in /dev/shm/.com.google.Chrome.CoFaUW failed: Too many open files
 [24082:24122:0526/084141:ERROR:raw_channel_posix.cc(139)] recvmsg: Connection reset by peer
 [24082:24122:0526/084141:ERROR:channel.cc(297)] RawChannel fatal error (type 1)

or (different page)

 [24082:24122:0526/084309:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
 [24082:24122:0526/084309:ERROR:crash_handler_host_linux.cc(212)] Received death signal message with the wrong size; msg.msg_controllen:56 msg.msg_flags:8 kCrashContextSize:1584 kControlMsgSize:56
 Parent failed to complete crash dump.
 [WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.
 [WARNING:flash/platform/pepper/pep_viewclient.cpp(357)] Could not create display context.
 [24082:24122:0526/084310:ERROR:raw_channel_posix.cc(139)] recvmsg: Connection reset by peer
 [24082:24122:0526/084310:ERROR:channel.cc(297)] RawChannel fatal error (type 1)

Same here out of 36.0.1985.67 beta

[31166:31272:0616/133953:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
[31166:31272:0616/133953:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
[31166:31272:0616/133953:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
[31166:31272:0616/133955:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer

This generally happen when I start to have a lot of tab open. Closing the window, and re-opening all the tab seem to fix the issue for a while, then here we go again.

Could this highlight a leak of some sort ?

I think I'm having the same issue in Google Chrome 36.0.1985.125

I don't have any extension installed. I don't turned on "Use hardware acceleration when available". It seems that it happens when it has to run some heavy javascript.

[3832:3863:0812/125822:ERROR:host_shared_bitmap_manager.cc(122)] Cannot create shared memory buffer
Parent failed to complete crash dump.
[3832:3863:0812/125822:ERROR:crash_handler_host_linux.cc(212)] Received death signal message with the wrong size; msg.msg_controllen:56 msg.msg_flags:8 kCrashContextSize:1584 kControlMsgSize:56
[3832:3863:0812/125822:ERROR:raw_channel_posix.cc(139)] recvmsg: Connection reset by peer
[3832:3863:0812/125822:ERROR:channel.cc(297)] RawChannel fatal error (type 1)

It's not clear why this hasn't yet gotten a fix, but we can work around this bug by editing the chrome loader script to set a higher ulimit.

For the dev channel on Ubuntu this script is located in:
/opt/google/chrome-unstable/google-chrome-unstable

(Or find your loader with: ls -l `which google-chrome`)

Add the following after the top comments:

ulimit -n 4096

You can test this before actually editing the script by opening a shell, typing in the command above, and then running google-chrome from within that session.

#12 Confirmed working workaround

Also confirmed ulimit increase works well.

this keeps happening with google hangouts plugin for me, repeated "aw, snap" tab crash, chromium version is 37.0.2062.120 (debian stable).

restart browser staves it off a while, but it comes back soon (tens of minutes).  however, just going to "maps.google.com" and moving around a bit reliably causes the tab-crash even shortly after browser restart.  I have about 35 tabs open in 5 or so windows (which get restarted across invocations), it looks like one process per tab, based on Chrome's Task Manager 'pid' field all being different numbers.

note that I only get shm error, never "too many open files."

note that my platform is software accel (blacklisted until later GLX version)

since making suggested workaround (increase to descriptor limit 1k -> 4k), my problem also has disappeared, no longer can reproduce.  tried heavy google maps usage for ten minutes (at 1k limit, was trivial to reproduce), no crashes.  will report back if they manifest after time.

single tab needing 1k descriptors for routine shm allocations seems excessive... this forces all users to "know" to raise this limit, sysadmin to do it on all systems which might run chrome (in pam login config or wherever) or upstream default per-process raised just for chrome...

It is ridiculous that this bug is still not fixed after more than a year. My chrome crashes a lot, at least a couple times a day. I started experience if a few months ago. Interestingly I did experience similar crashes last year, but it stopped. Now it's back again.

The bug is the same as explained above. Tabs start to crash with "Aw snap" and then the whole browser. Often the browser crashes when I try to restore my previous tabs after I came back from a crash. Every time there are "too many open files" errors in the log.

This bug makes the browser unstable and unreliable. It makes working and browsing painful. For this, this bug should be considered serious.


Problem #1: The bug itself.
Problem #2: This bug exists for more than a year without a fix and noone seems to care.
Problem #3: There is a workaround which is not already in the release. Noone has ever tought of that?
 

Chromium Version 37.0.2062.120 
Built on Debian 7.6, running on Debian 7.9 (281580) (64-bit)

Recently upgraded from 4G of RAM to 8G. Naturally, within days, my number of persistently-open tabs jumped to around 60-80. Naturally (?), Google's own websites were among the worst-crashing offenders.

Editing the launcher script to include a ulimit command, worked.