Chrome Version: 57.0.2987.133 (Official Build) (64-bit)
OS: Windows 10

This happened on a Windows 10 partition on my personal 2016 MacBook Pro. Shortly after boot up and launching Chrome, it froze for a number of seconds.

Once it recovered, I went to check chrome://profiler and sorted by browser process & UI/IO thread to see if any task took a long time on the UI/IO threads and indeed saw the following on the IO thread:

Count	Total run time	Avg run time	Max run time**	Avg queue time	Max queue time	Birth thread	PID	Function name	Source location
1	10,085	10,085	10,085	0	0	Chrome_IOThread	796	DiscoverOnAddresses	dial_service.cc [512]

So the above says there was a function call that tooks 10s on the IO thread in browser process, with the function name of the FROM_HERE posted task being DiscoverOnAddresses in dial_service.cc. Looking at that code, we see the FROM_HERE invokes DialServiceImpl::FinishDiscovery():


    finish_timer_.Start(FROM_HERE, finish_delay_, this,
                        &DialServiceImpl::FinishDiscovery);

The problem is this work is being done on the IO thread, which is also responsible for routing IPCs - so during this 10s task, no IPCs were routed and thus Chrome was essentially frozen (e.g. UI was not interactive, pages did not respond).

If this work can be blocking - as it seems to be the case here - then it shouldn't be done on the IO thread - instead it should be on the blocking pool.

Assigning to zhaobin@ who recently touched this code. Please re-assign to a better owner if there is one. Thanks!