By code investigation following issues were found:

First issue:
1. Chrome is run.
2. Hostname is changed.
3. Chrome crashes, leaving the lock file with the old hostname.
4. A different chrome runs with a different user-data-dir and just happens to
get the same pid as from step #1.
5. Chrome is run again with the original user-data-dir. It sees there is a lock
file with a different hostname, but sees that there is a chrome process with the
same pid, so it can reach the KillProcessByLockPath in the connect retry loop.

In this case, lockfile is not deleted. We need to delete lock file without killing anything.


Second issue:
1. Chrome is run.
2. Hostname is changed.
3. Chrome freezes, it's still listening on the socket with the old hostname, but
not responding to any messages.
4. Chrome is run again. It can connect to the socket, but times out waiting for
a response, hitting one of read timeout or write timeout KillProcessByLockPath
calls.

In this case, we'd actually want to kill the frozen chrome in addition to deleting the lockfile, which the code currently doesn't do.

Please provide a server crash id for the "first issue" crash. For the second issue, please use Activity Monitor to take a sample of Chrome when it freezes.

This isn't WebSocket-related. I think it concerns the ProcessSingleton class in //chrome. I am guessing that UI>Browser>Profile is the correct component.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67095448eb212b9f8e09f071515669d9618e7534

commit 67095448eb212b9f8e09f071515669d9618e7534
Author: aseren <aseren@yandex-team.ru>
Date: Tue Jun 06 18:14:12 2017

Fix process_singleton_posix handling of hostname changes not deleting a stale
lockfile or not killing a frozen browser.

First issue:
1. Chrome is run.
2. Hostname is changed.
3. Chrome crashes, leaving the lock file with the old hostname.
4. A different chrome runs with a different user-data-dir and just happens to
get the same pid as from step #1.
5. Chrome is run again with the original user-data-dir. It sees there is a lock
file with a different hostname, but sees that there is a chrome process with the
same pid, so it can reach the KillProcessByLockPath in the connect retry loop.

In this case, lockfile is not deleted. We need to delete lock file without killing anything.

Second issue:
1. Chrome is run.
2. Hostname is changed.
3. Chrome freezes, it's still listening on the socket with the old hostname, but
not responding to any messages.
4. Chrome is run again. It can connect to the socket, but times out waiting for
a response, hitting one of read timeout or write timeout KillProcessByLockPath
calls.

In this case, we'd actually want to kill the frozen chrome in addition to deleting the lockfile, which the code currently doesn't do.

CL fixes both of these issues.

R=jochen@chromium.org, mattm@chromium.org
BUG= 722749 

Review-Url: https://codereview.chromium.org/2880333004
Cr-Commit-Position: refs/heads/master@{#477342}

[modify] https://crrev.com/67095448eb212b9f8e09f071515669d9618e7534/chrome/browser/process_singleton.h
[modify] https://crrev.com/67095448eb212b9f8e09f071515669d9618e7534/chrome/browser/process_singleton_posix.cc
[modify] https://crrev.com/67095448eb212b9f8e09f071515669d9618e7534/chrome/browser/process_singleton_posix_unittest.cc

Alexey, is it fixed? Should I close the bug?

Friendly ping. Can we close this bug and mark is as Fixed?

I'm sorry for the late answer. The issue was fixed now and we can mark it as Fixed.

Thank you for providing more feedback. Adding requester "shrike@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