https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
Bug ID: 110016
Summary: [12/13/14] Possible miscodegen when inlining
std::condition_variable::wait predicate causes
deadlock
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amy at amyspark dot me
Target Milestone: ---
Created attachment 55181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55181&action=edit
Minimum test case to reproduce the deadlock
Hi all,
This is to report a possible codegen issue when inlining a lambda predicate for
std::condition_variable::wait. We've verified this to happen with the following
versions:
- g++-8 (Homebrew GCC 8.5.0) 8.5.0
- g++.exe (Rev6, Built by MSYS2 project) 13.1.0 (both UCRT64 and MINGW64)
- g++
(Compiler-Explorer-Build-gcc-4579954f25020f0b39361ab6ec0c8876fda27041-binutils-2.40)
14.0.0 20230522 (experimental)
The deadlock seems to happen with 100% certainty on GCC 12.2.1 if one enables
ThreadSanitizer; otherwise it happens sporadically in CI.
I packaged a reduced version of the test suite:
https://godbolt.org/z/fj8rnrbo7, a copy of which you'll find attached to this
report. Build with `-std=c++17 -pthread -O2 -fsanitize=thread`.
In all cases, once the deadlock is hit (wait for ~3 seconds under GDB) the
"finished" atomic boolean and the "workQueue" are correctly flagged as true and
empty, respectively; however, the thread will still wait for the condition
variable indefinitely. This can be easily worked around by blocking the
inlining eg. turn the lambda into a std::bind instance.
The complete code of the library where we reproduced this is available here:
https://github.com/bad-alloc-heavy-industries/substrate/tree/375db811308ad7414771dbde9af4efa7aa393ca8.
You can build it with `meson setup build -Dcpp_std=c++17 -Db_sanitize=thread`
and run the test with `meson test -C build`.
