Thanks for the crash report.

bc21937eb3238da0   [Assert] base::WaitableEvent::WaitMany bug 761970
5b12d6b0ec87d243   "
18f5f53c76fcab28   "
afaaa93c1256fa34   blink::ConvertNSColorToColor  bug 747776
787c69694e0f9ab7   [Assert] base::WaitableEvent::WaitMany
a897c0ca1a2df8ae   [Assert] gin::V8Initializer::LoadV8Natives  bug 501799
658efe2a1d49e4ad   event_del
9fe2f3c019e8b0f3   [Assert] base::WaitableEvent::WaitMany
a1e3d7d93785ea19   ChromeMainDelegate::PreSandboxStartup   bug 650162
9a2246ce1bb94500   sandbox::logging::PFatal
2187bde31872f115   [Assert] base::WaitableEvent::WaitMany

A lot of these are associated with the error "Too many open files in system (23)".

Do you have a lot other processes on the system running, or a lot of tabs open?

We do not currently provide debug symbols for Mac, though that request is tracked by issue 693626.

Possibly this was caused by 'too many files', as I had similar issue in the past, but this time I didn't have any indication what's the problem. Restarting system helped, we'll see for how long.

I've already have limit increased to 10k as per:

$ sysctl -a | grep files
kern.maxfiles: 10240
kern.maxfilesperproc: 4096
kern.num_files: 9270

But probably it's not enough, as I've already 9k files open since yesterday restart.

I think it would be great that Chrome could not crash when there are too many files in the system, but anyway. If you think there is not much to fix here regarding 'too many files' issue, please close it.

Currently I've manually increased limit by:

$ sudo sysctl -w kern.maxfiles=20480
kern.maxfiles: 10240 -> 20480

As setting the limit in /etc/sysctl.conf on macOS didn't work as expected:

$ cat /etc/sysctl.conf
kern.maxfiles=20480
kern.maxfilesperproc=4096
kern.maxprocperuid=1000
kern.maxproc=2000
kern.maxvnodes=524288

Thanks for the update! 
@rsesek : Could you please look in to this issue.

Thank You!

This could also indicate a problem with another program, I think. Does quitting any program other than Chrome resolve it without a restart?

I don't have problems with another programs. Limit of 10240 maximum files is a standard and I easily reaching 9k without specific app in mind after hours of working. For example I'm using git on repositories for 50k files. There is nothing unusual, but when using Chrome with plenty of user profiles, windows and tabs, it just crashes.

Ideally it shouldn't crash when there are too many files open in the system.

As for workaround, I've added the following lines into: /etc/rc.local file
launchctl limit maxfiles 65536 unlimited
sysctl -w kern.maxfiles=20480
ulimit -c unlimited

and will test on the next reboot which should increase the kernel and launch file limits.

Thank you for providing more feedback. Adding requester "sdy@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I also use git on repos with lots of files (e.g. Chrome) — the thing that bugs me about this issue is that nothing should *leave* those files open. Or, to put it another way, restarting shouldn't fix anything.

Just to satisfy my curiosity, would you mind running something like this the next time you're in this state, right after Chrome crashes?

    $ # From https://stackoverflow.com/questions/795236/in-mac-os-x-how-can-i-get-an-accurate-count-of-file-descriptor-usage
    $ sudo lsof -d '^txt' | awk '{print $1}' | uniq -c | sort -rn | head

It might provide some insight into where the open files are going.

Actually, maybe I misunderstood your last comment. Are you saying that, even immediately after a restart, launching Chrome and loading all of your profiles, tabs, etc. causes this crash?

I'm restarting MBP very rarely apart of closing the lid (sleep), so after couple of days when I'm using Chrome with all tabs open, it's crashing at random when I hit limit of open files. Please note that the unix sockets are counted as open files. And I've 9.5k open files as we speak as per:

$ sysctl -a | grep num_files
kern.num_files: 9532

where half of it comes from Google web browsers.

I'm attaching the file which list at least 3.8k of open files only by filtering by Google pattern.

Thank you for providing more feedback. Adding requester "sdy@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I'm not sure if that list accurately represents the number of open files that Chrome is consuming.

- Could you run that command (`sysctl -a | grep num_files`) while Chrome is running, then quit Chrome and run the command again to see how the number changes?

- Could you run the command line I showed in #8 to see what else is consuming open files?

```
$ sysctl -a | grep num_files
kern.num_files: 10680
$ pkill Google
$ sysctl -a | grep num_files
kern.num_files: 9157
$ pkill -9 Google
$ sysctl -a | grep num_files
kern.num_files: 7293
$ echo $((10680-7293))
3387
```

It looks like it was consuming 3387 files, so 1/3 of the total in the system.

My main concern is, is it possible to implement any failing scenario, so at least it's known why it's crashing. Some kind of try/catch block?

I guess I had similar crash in  Issue 783195  which was not reproducible after restart.

Thank you for providing more feedback. Adding requester "sdy@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Oh, that's interesting. The first pkill should have shut down all Chrome processes (but I would recommend just killing/quitting the main process, it should shut the others down cleanly as it exits).

What Chrome processes are left over after you quit Chrome normally, via the GUI? After it exits, check with `pgrep -lf Chrome`. If anything is left, that could be part of the problem.

7k still seems unusually bit high to be left over after exiting Chrome. Did you run that lsof command to see if any other processes are using an unusual number of FDs too? It's fine if you don't want to share the output, I just want to know whether there are any other offenders.

Re. your question, rsesek@ might know better, but as far as I know, running out of FDs happens rarely, and Chrome can't really do anything about it (there isn't anything Chrome can do except exit, and there's nothing particularly helpful that Chrome could tell the user in an alert). So, the decision was probably made to not maintain any special handling for it. 

s/unusually bit high/unusually high/

Mac triage: marking issue WontFix after 30 days without feedback.

Reporter: if you do have additional feedback, feel free to comment again on this issue - doing so will reopen it.