WebSockets implementation is seemingly failing to set the pool_id for the handle, which is triggering a CHECK_NE that pool_id_ != -1.

Looking at version, we see this has been going on for quite a while, so it's not related to the removal of the TransportConnectJobHelper.

Someone from WebSockets should triage why "set_pool_id()" isn't being called on the ClientSocketHandle for the Websocket pool.

https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%20CONTAINS%20%27net%3A%3A%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BAssert%5D%20net%3A%3AClientSocketHandle%3A%3AHandleInitCompletion%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:15,productversion is more representative.

Removing RVG here; it's a benign/intentional CHECK() failure.

Oops, I found this is different from issue 641013.

Refactoring for this issue: https://codereview.chromium.org/2328453002/

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

commit 913f8b743b1922bd332f01d7456ad688b80463cf
Author: tyoshino <tyoshino@chromium.org>
Date: Fri Sep 16 07:52:38 2016

Refactor WebSocketTransportClientSocketPool's socket handing out code

Tries to make the code a little more readable to help debugging the
associated bug.

For the OK result, BoundNetLog::EndEventWithNetErrorCode() was called
after BoundNetLog::EndEvent() in
WebSocketTransportClientSocketPool::RequestSocket(). Fixed this to call
only EndEvent().

Removed pre-condition checks before ActivateStalledRequest() which are
already performed by its while loop.

Added DCHECK_NE(error, OK) to FlushWithError() to make sure OK is never
received from that path.

Reordered some lines.

R=yhirano@chromium.org,mmenke@chromium.org
BUG= 642363 

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

[modify] https://crrev.com/913f8b743b1922bd332f01d7456ad688b80463cf/net/socket/websocket_transport_client_socket_pool.cc
[modify] https://crrev.com/913f8b743b1922bd332f01d7456ad688b80463cf/net/socket/websocket_transport_client_socket_pool.h

As far as I investigated, it looks whenever the callback is invoked, set_pool_id(0) is invoked. Hmm.

We see only a few reports for M53-55.

REGEXP(product.name, '^Chrome') AND
  REGEXP(product.version, '^(53|54|55)')
  OMIT RECORD IF
    SUM(CrashedStackTrace.StackFrame.FunctionName='net::ClientSocketHandle::HandleInitCompletion(int)') = 0

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

The issue still exists:

https://crash.corp.google.com/browse?q=product.name%20CONTAINS%20%27Chrome%27%20AND%20product.version%20%3E%3D%20%2755.0.%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%20CONTAINS%20%27net%3A%3AClientSocketHandle%3A%3AHandleInitCompletion%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

Still happening:

https://crash.corp.google.com/browse?q=product.version%20%3E%3D%20%2755.0.%27%20AND%20expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%20LIKE%20%27net%3A%3AClientSocketHandle%3A%3AHandleInitCompletion%25%27

This crash shows a strong preference for Mac.

Maybe something to do with Mac's large number of localhost connection refused errors?

Crash analysis has not encountered any reports for this bug for the past 90 days. We have added the label 'crash-BugNoRepro'

Crash analysis will be automatically closing the bug in 6 days. If you do not want Crash analysis to automatically close the bug, please remove the label 'crash-BugNoRepro'. If you have any feedback on this feature, please contact pranavk@

Crash analysis has not encountered any reports for this bug for the past 90 days. Hence as per the comment 10 days ago, we are closing the bug and setting the status to WontFix. If you have any feedback on this feature, please contact pranavk@