Does this generate any crash id under chrome://crashes?

As a matter of fact, yes. Try crash/8c6204fb00000000.

I also realize I must have misfilled part of the template above.  When I triggered said crash, the whole group of tabs on the same site crash.

Another way of reproducing this I found is to leave a Chrome Tab open on Ubiquiti EdgeMAX/EdgeRouter admin page - after login it displays a continuously updating graph and that seems to get the page to go Aw Snap resulting in below kernel message -

map: chrome (3745): VmData 2147667968 exceed data ulimit 2147483647. Update limits or use boot option ignore_rlimit_data.
[ 3604.628411] do_trap: 204 callbacks suppressed
[ 3604.628413] traps: chrome[3745] trap invalid opcode ip:55fe0747f2a2 sp:7ffd1ea8df60 error:0 in chrome[55fe0576f000+6430000]

From abrt coredump under gdb - this is what can be seen - 

Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/google/chrome/chrome --type=renderer --enable-features=*AutofillCreditCard'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000055fe0747f2a2 in ?? ()
(gdb) disassemble 0x000055fe0747f2a2,0x000055fe0c16d218
Dump of assembler code from 0x55fe0747f2a2 to 0x55fe0c16d218:
=> 0x000055fe0747f2a2:	ud2    
   0x000055fe0747f2a4:	data16 data16 nopw %cs:0x0(%rax,%rax,1)
   0x000055fe0747f2b0:	movb   $0x1,0x21(%rdi)
   0x000055fe0747f2b4:	lea    0x828(%rdi),%rcx
   0x000055fe0747f2bb:	add    $0x1e000,%rdi
   0x000055fe0747f2c2:	xor    %eax,%eax
   0x000055fe0747f2c4:	jmp    0x55fe0747f2e0
   0x000055fe0747f2c6:	mov    %rcx,%rsi
   0x000055fe0747f2c9:	and    $0xfffffffffffe0000,%rsi
   0x000055fe0747f2d0:	mov    0x1028(%rsi),%rsi
   0x000055fe0747f2d7:	jmp    0x55fe0747f2fa
   0x000055fe0747f2d9:	nopl   0x0(%rax)
 [...]

I encountered this crash several times when uploading large files (say 8gb) via photos.google.com

[1214641.685293] mmap: chromium (4086): VmData 2147561472 exceed data ulimit 2147483647. Update limits or use boot option ignore_rlimit_data.

As per crash server the stack trace for crash ID 8c6204fb00000000 looks similar to issue 627529 which got fixed

 kainite@, Could you please try the same on latest stable version 55.0.2883.87 and see if issue exists.

Sure, it may take me a day or two to verify and test with the same setup I'd have ad before.

Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi, I've been running into this issue occasionally over the last couple of months.

I can confirm it's still an issue on 64-bit Linux w/ver 
Google Chrome	56.0.2924.87 (Official Build) (64-bit).

Test case: Put a few hundred YouTube embeds in a HTML page. Either start going through & playing and pausing the videos one at a time, or just open the Chrome DevTools.

(The tab process manages to keep itself under the 2GB limit when it's static - with difficulty - but once the DevTools are invoked or you're skipping through the 9th or 10th video, the tab will definitely OOM and crash.)

Crash dump id: ada5bbe120000000

(^ Crash captured by opening dev tools while the very long page w/youtube embeds loaded. No extensions loaded or weird flags passed.)

I have tried futzing with ulimit myself, but I believe as a previous poster pointed out that this is part of the sandboxing stuff you do to your rendering processes.

Yeah I'm loading a pretty worst-case webpage, but I've got 24GB of RAM. Would you be willing to double the tab mem limit to 4GB, in line with Windows? :)

Thanks for your consideration.

Seems stack trace is simiar to #675855,hence merging the issue.
Please feel free to undup if this is not similar.
Thank you!!

675855 is a restricted bug, I don't have permission to view. Given the environmental distinguishing factors of this bug, can someone comment on whether or not those are part of the restricted bug?