https://bugs.llvm.org/show_bug.cgi?id=43389
Bug ID: 43389
Summary: possible deadlock in termination path on Windows
Product: libc++
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: compn...@compnerd.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Consider the following program:
```
#include <cstdio>
#include <cstdlib>
#include <iostream>
#include <thread>
int main()
{
std::setvbuf(stdout, NULL, _IOLBF, 0x1000);
std::cout << "Hello, world!";
_lock_file(stdout);
std::thread t([&] { std::_Exit(0); });
t.join();
return 0;
}
```
The `std::_Exit` will invoke the DLL destructors, from the invoking thread and
after terminating all other threads in the process. Because the main thread
was holding the lock on `stdout` when it was terminated, this will result in an
orphaned CriticalSection which the DLL destructor will attempt to acquire.
Fortunately, Windows will identify that the CriticalSection is orphaned and
terminate the program. This is not however guaranteed, and if the underlying
libc does not use a CriticalSection to handle the locking, the application may
deadlock.
This is visible to the user by having the program be terminated by a ^C sent to
the application while the application is writing to the console (and thus
acquiring the lock to the output stream). The destructor will attempt to flush
the stream before program termination, which will attempt to re-acquire the now
orphaned lock.
https://github.com/llvm-mirror/libcxx/blob/master/src/iostream.cpp#L135-L148
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
