[llvm-bugs] [Bug 44211] New: LLVM ThreadPoolExecutor incompatible with Windows global destructors in a DLL

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44211

            Bug ID: 44211
           Summary: LLVM ThreadPoolExecutor incompatible with Windows
                    global destructors in a DLL
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: laurenzo at google.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

When using the LLVM ThreadPoolExecutor (lib/Support/Parallel.cpp) on Windows
within a DLL, its global destructor will deadlock on DLL unload (or process
shutdown).

In short: In DLLs, by the time that global destructors are called in a DLL, all
threads have been forcibly stopped already, making global destructors that rely
on thread shutdown handshakes unworkable. LLVM's ThreadPoolExecutor is one such
thing. This can be seen by setting a breakpoint in the work() method and the
destructor. You will note that by the time the destructor is called, there are
no further threads running, and you will never hit the breakpoint (prior to
that) where the thread exits.

This is the same root cause as encountered on the dlib project (which is where
I found some debugging inspiration):
https://github.com/davisking/dlib/issues/505

I do not have a repro of this issue currently as I am working quite downstream
and it requires a specific setup on Windows to trigger. However, it took a fair
bit of diagnostic work that would be helpful to have captured.

Since the ThreadPoolExecutor is sparsely used at present, this may be a newly
discovered issue. I believe that in the current state, it would only affect
LLDB when used in a DLL (or MLIR from a DLL, which is where I encountered
this). My fix was to disable LLVM threading on windows.

The consensus from others seems to be that a fix would involve some Windows
specific code that installed an atexit hook on static construction. This hook
would poke the ThreadPoolExecutor and tell it to do an orderly shutdown.
Apparently on Windows, an atexit hook in a DLL is called before the OS forcibly
stops dependent threads.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191203/a361edda/attachment.html>