I can't repro the issue on my MacOS.

shawnsmithj@: If this applies to Safari as well, it sounds unlikely a chrome specific regression but a system proxy issue. 

Have you ever tried downgrade to an older version of Chrome and see if the issue persists? Or did you observe the same issue if you connect to a non-enterprise network?

In any case, need a bit more information to help here. Can you please reproduce this problem and follow the instructions below to attach a net-export dump?
https://dev.chromium.org/for-testers/providing-network-details

Thanks. With the overlap with Safari it definitely feels like some kind of bad interaction with the system proxy. Unfortunately, I can't capture a network dump because even the internals won't load when it occurs. Would a spin dump or some kind of other debug info help?

Thank you for providing more feedback. Adding the requester to the cc list.

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

As per comment #0 and #1, it seems that the issue need to be tested on enterprise system. Hence, forwarding the issue to inhouse enterprise for further triaging of the issue.

Thanks...!!

If even about:net-export fails to load, this doesn't sound like a network issue at all, but rather a system issue (Unable to launch a process?  Some huge memory leak in some other process?  Bad RAM?).  I don't think there's anything we can do here, considering this affects Safari as well, and isn't network related.  Removing the network label, as Chrome internal pages aren't loaded over the network.

Seems it is out of scope from TE end as it is related to kerberos authenticated (active Directory) proxy server which we do not have the same , adding TE-NeedsTraige-help label to move this out of our triaging bucket and removing Needs-TestConfirmation and Needs-Bisect for now.

Could someone from dev team please take a look into this issue.
Thanks..!

[+asanka]:  The mention of Kerberos and M69 indicates it may be a dupe of  issue 872665 , but the symptoms (Chrome hanging, affecting Safari) don't sound like that issue, unless there's an underlying Kerberos bug where failed authentication borks some sort of ambient system state.

Hmm. Let's keep this separate since we are also seeing some macOS failures on the stable builders. When I get in I'll check if there's been any Heimdal (macOS's Kerberos stack) changes that was pushed at the same time.

Bumping priority in case any more code changes are needed.

My enterprise is experiencing what appears to be the exact same problem and symptoms as described above. Mac OS 10.13.6 with Chrome 70.0.3538.77. 

Chrome will first begin to slow down, and eventually we are unable to open anything under chrome:// Safari will be unusable as well. Firefox continues to operate normally. Eventually the entire OS slows to a crawl and locks up, with a hard reboot required to get back to a working state. Users can go between 3 hours to over a week before they experience the issue again.

We are using the Zscaler Agent for proxy.

If it affects Safari, too, it's not a Chrome issue.  FireFox uses its own proxy settings, while Chrome uses the system ones, so I'd take a look at Zscaler Agent, though could certainly be something else.

We believe we have resolved this by updating to the latest Symantec DLP plug in. Chrome appears to work poorly with the older versions and eventually hangs causing the plug in and DLP systems to hang other browsers. 

We happen to be running Symantec DLP as well. We will look into updating it or removing it. Thanks Shawn for the lead.

Unassigning since this doesn't seem to be Kerberos.

As for the hangs,  could someone follow https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs and get us a stack?

+bheenan@ FYI

Thanks for including me. Coincidentally, my partner has seen this problem at her work too. I filed a similar issue ( https://crbug.com/893782 ) but then it stopped repro'ing. It showed up in M69 (stable channel) for her.

Removing the Enterprise component as this does not seem to be related to enterprise policy / cloud management.

Actually, this does seem to be related to an enterprise set up (even though it's not policies/deployment/management specifically), so adding Enterprise component back for tracking

I've been seeing this as well, at a large enterprise. Can any of you share the specific Symantec DLP version you are seeing it with?

Ping anyone who can repro: please follow instructions in comment #16 and upload a crash dump.  Thank you.

FYI, I think my  issue #904884  is in fact this same issue, but can't get you a crash dump right now... because this very bug convinced our enterprise to turn off Symantec DLP at this time to figure out how to handle the Mac Chrome crashes.

 Issue 904884  has been merged into this issue.

Anyone still having this issue, and able to provide the information requested in comment #16?  If Symantec has resolved this on their end, we may just want to close this bug.

Archiving since this the requested information is not provide. Please reopen if this is still an issue.