Proposed solution: https://codereview.chromium.org/2857743004/

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

commit abecaf4066bdffab7af3e26102d2e2644835d8a9
Author: mmarkowicz <mmarkowicz@opera.com>
Date: Fri May 05 10:18:18 2017

Workaround for UCRT deadlock between gpu's main and watchdog threads

Deadlock is likely caused by UCRT lib bug that can be reproduced with
low-frequency in Opera Browser on Windows 7. Deadlock will permanently freeze
gpu process (watchdog will not intervene as, ironically, it's involved in a
deadlock).

BUG= 718388 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/abecaf4066bdffab7af3e26102d2e2644835d8a9/gpu/ipc/service/gpu_init.cc

jbauman@ this looks fixed above.  Could you close once verified?

Although this issue is closed, I wanted to share my experience dealing with the same deadlock (in our application, it occurred between different threads than reported in this issue).

Our application at Bloomberg embeds Chromium, but at the moment the circumstances of how we run Chromium are different from Chrome - we run the browser and the renderer in the same process, and we run an 'in-process-gpu' - which probably led to us encountering this deadlock frequently once we migrated to the Chromium 53 codebase (we have been using the fixed version of the UCRT for some time now).

Our deadlock was due to the main thread trying to acquire the Windows loader lock (while UCRT's '__acrt_eagerly_load_locale_apis()' builds a cache of pointers to locale-related functions, stored in an array called 'encoded_function_pointers' defined in 'winapi_thunks.cpp' & not visible outside of that object file) after earlier acquiring the locale lock, and a second thread (at times GPU-related, but later just some 'worker thread' created for a purpose unknown to me) trying to acquire the locale lock (while UCRT's 'construct_ptd()' sets up per-thread data for the newly constructed thread) while the loader lock is held (because the per-thread data is initialized during the 'DLL_THREAD_ATTACH' path of a call to '_DllMainCRTStartup()').

Linking the UCRT statically seems responsible for introducing this deadlock. When the UCRT is linked statically, there will be a copy of the array 'encoded_function_pointers' for each DLL loaded into the process, so it may get initialized several times, sometimes outside of the DLL's 'DllMain()' when the loader lock isn't held. When the UCRT is linked dynamically, there will be only one copy of 'encoded_function_pointers', and it will get initialized by some early call to 'setlocale()' during 'DllMain()' (e.g., while setting up the C++ standard streams library).

I believe that this deadlock was introduced during GPU thread initialization because the two ANGLE DLL's get loaded at that time, each introducing their own copy of 'encoded_function_pointers'. Our own case was further complicated by the fact that we've split V8 into its own DLL, which created a much more fertile breeding ground for this deadlock.

Our own workaround for this is to introduce a 'DllMain()' to each of our DLL's (v8, blink & the rest, ANGLE EGL and ANGLE GL) which calls 'setlocal(LC_ALL, NULL)' during 'DLL_PROCESS_ATTACH'.

It's a mystery to me as to why this was introduced by us moving to the Chromium 53 codebase from Chromium 50, when both linked (statically) to the same version of UCRT (10.0.14393), although since the compiler changed from VS 2013, to VS 2015, perhaps that played a role.