Do you also experience this in an incognito window or in a different browser?

We'll probably end up needing the net-internals log to triage this further.

Yes, I saw it in an incognito window.

I did a save to file in net-internals, but how private is the net-internals dump? Obviously I'm hesitant to post a dump of my private Facebook stuff to the open internet

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

As long as you leave the 'strip private information' bit unchecked and don't check the 'include actual bytes' boxes (on Export and Capture respectively), it'll only include the metadata of the requests. We can also restrict the post to be Googler-only. Details at:

https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

You don't happen to have any ad blocking or content blocking extensions installed?

I notice in net-internals that socket pools are way below the max column. Is that expected?

For example, it's stalling now and I see handed out:3 idle:0 connecting:0 max:32

Could it be that more sockets should be generated to get closer to that max when they're all handed out already?

Alright, here's a dump. No, I disabled the blocking extensions

Deleted: net-internals-log (1).json 2.4 MB

net-internals-log (1).json 2.4 MB View Download

Tested the issue on ubuntu 14.04 using chrome M58 #58.0.3029.41 and followed below steps :

1. Opened www.facebook.com in chrome and logged into it.
2. refreshed the page and observed , ui has rendered correctly.

@chrisrcarlin-- Could you please provide us the screencast of the issue , if you can reproduce it consistently , that would help us in traiging the issue better.

Thanks1

When running the non-beta version of chrome everything is fine, and on net-internals I see 20 to 32 sockets handed out. Again that brings my attention to the three sockets handed out on the beta version that stalls.

Any idea what could cause so few sockets to be handed out? Is there any tweak I can make to try to help Chrome hand out more sockets to see if it fixes the issue?

Yes, the issue is pretty consistent happening around 70% of the time. I might be able to see about a screencast, and I wonder whether a dozen other open tabs might have something to do with it not being reproducible as per comment 8.

Thank you for providing more feedback. Adding requester "hdodda@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 the # of sockets handed out is the right signal here. Facebook uses H2 so we should be multiplexing over fewer sockets.

From the log, it looks like the H2 connection to FB stalls at 3044 and 10040 after Chrome sends a POST request.

I wonder if this could be an issue with FB itself? Adding Internals>Network>HTTP2 for more eyes.

In the netlog attached to comment #7, there is exactly one HTTP/2 connection to Facebook, that's source number 437687.  Stream 87 is served by Facebook's server, but stream 89, https://www.facebook.com/rsrc.php/v3/y8/r/T7pRU1Lt9ka.js, is not.  There's a lot of data flowing through until t = 3077.  There's a large number of requests dispatched by that time that go unanswered, and there's a few more requests sent later.  Nothing from the server for another 14 seconds when logging stops.  No connection error, timeout, anything like that either.

What should I do next for debugging?

Turns out this has SOMETHING to do with IPv6.

Turning off IPv6 made the problem go away. But then the weird thing is, going over IPv4 to a proxy (both http and https tunnel) that itself supported IPv6 had no trouble.

I then turned IPv6 back on but specified the proxy with an IPv4 address, and everything kept working.

Soooo... who's at fault? :) It doesn't seem like it should be a Facebook problem since they're successfully responding to the proxy over IPv6.

Interesting find.  Maybe a network device is IPv6-intolerant between the client and the proxy?  Nothing stands out from the network log on Chrome's end: DNS resolution succeeds, and the first 40 or so requests do not get blackholed.

I have something new to investigate: I happened across an IPv6 testing tool last night that said there was an MTU mismatch somewhere.

It MIGHT BE that my ISP is screwing up their MTU in a way that would cause some responses from Facebook over IPv6 to drop, which may explain this behavior.

At this point I'm suspecting chromium isn't the problem, but I haven't had a chance to really look into the issue yet. If I can confirm the MTU mismatch theory, then it would pardon chrome.

Maybe this bug should be marked needs-feedback for now?

Are you still able to easily reproduce this issue over IPv6?

I set my home router to a lower MTU and so far the issue isn't showing up.

This kind of makes sense: I understand that IPv6 leaves MTU issues up to the endpoints, so chromium wasn't receiving MTU busting responses from Facebook, so it was hanging.

Would you like me to put the MTU back up and see if I can still reproduce it?

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

Yes.  Can you undo your MTU change, try to repro over IPv6 and grab a pcap (all traffic should be encrypted with https)?  Another thing to try would be to set `sysctl net.ipv4.tcp_mtu_probing=1` and see if that fixes it.

Yep, tried it again and MTU caused the same problem.

Removing from bisect bucket since TE cannot repro.

Based on the reports above it seems like this is not a Chrome bug.