Rare hang (~1 in 3000) in grpc when using abseil sync primitives on Windows.

[malkia]

Describe the issue

A more detailed issue is here grpc/grpc#39321 and originally here where it was first noticed - open-telemetry/opentelemetry-cpp#3372

Steps to reproduce the problem

A repo with steps is here - https://github.com/malkia/grpc_absl_hang

What version of Abseil are you using?

20240722.0 (found by bazel dep graph)

What operating system and version are you using?

Windows 10, 11

What compiler and version are you using?

Visual Studio Enterprise 2022, 10.0.26100.0 Windows SDK, and MSVC 14.43.34808, e.g.

C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.43.34808/bin/HostX64/x64/cl.exe

What build system are you using?

bazel 8.2.1

Additional context

No response

[nickhutchinson]

User of Abseil here -- saw this scary-looking ticket and wanted to make sure my project wasn't vulnerable.

Does the issue still present if you replace the use of std::_Exit() with std::exit()? The Windows implementation of std::_Exit seems a bit dubious -- reading the source in the UCRT source code (look for exit.cpp in your Windows SDK install) in most cases it boils down to a call to Win32's ExitProcess().

But ExitProcess() is somewhat dangerous -- it abruptly terminates all but the current thread, without invoking the threads' destructors for thread-local objects. However, destructors of thread-locals for the thread calling ExitProcess() are evidently still executed. This is bad news if any of the thread-local object dtors acquire a lock -- and Abseil's do -- because that lock might end up being held a thread that was killed.