[Bug libstdc++/98449] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Bug ID: 98449 Summary: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Details of the issue can be found at: https://cplusplus.github.io/LWG/issue3343 I have a code base affected by this issue.
[Bug libstdc++/108859] New: Exception thrown by std::filesystem::copy() is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108859
Bug ID: 108859
Summary: Exception thrown by std::filesystem::copy() is wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vini.ipsmaker at gmail dot com
Target Milestone: ---
std::filesystem::filesystem_error::path1() and
std::filesystem::filesystem_error::path2() should contain the paths for the
most deeply-nested call, not the outermost call. It's discarding information
regarding the error that actually occurred.
#include
#include
int main(int argc, char *argv[])
{
try {
std::filesystem::copy(std::filesystem::path{argv[1]},
std::filesystem::path{argv[2]},
std::filesystem::copy_options::recursive);
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << e.what() << '\n' << e.path1() << '\n' << e.path2() <<
'\n';
}
}
If a file already exists, path1() should not be argv[1], but the file that
failed to copy. Same for path2().
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 --- Comment #3 from Vinícius dos Santos Oliveira --- LLVM's libcxx already applied this 1-line patchset: https://github.com/llvm/llvm-project/commit/64fc3cd55d586498dd21c5b3cfaa755793913772 Can we have the same here on GCC side (I've already submitted the patch earlier).
[Bug libstdc++/108861] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 Bug ID: 108861 Summary: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Created attachment 54493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54493&action=edit bugfix Releasing the mutex before the call to notify_all is an optimization. This optimization cannot be used here. The thread waiting on the condition might destroy the associated resources -- mutex + condition variable -- and the notifier thread will access an destroyed variable -- the condition variable. In fact, notify_all_at_thread_exit is meant exactly to join on detached threads, and the waiting thread doesn't expect for the notifier thread to access any further shared resources, making this scenario very likely to happen. The waiting thread might awake spuriously on the release of the mutex lock. The reorder is necessary to prevent this race. LLVM's libcxx already fixed the issue: https://github.com/llvm/llvm-project/commit/64fc3cd55d586498dd21c5b3cfaa755793913772
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Vinícius dos Santos Oliveira changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #2 from Vinícius dos Santos Oliveira --- > Isn't this just Bug 98449? Why did you close that as FIXED? Nobody is going to fix 98449. The ONE-line patchset fixing the issue was there for YEARS. Why does it take so many years to review ONE line? It's obvious that it'll just hang there forever. Meanwhile I have a code base affected by this issue.
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #5 from Vinícius dos Santos Oliveira --- > Because there is an open defect report against the C++ standard about this. > Basically until that is resolved, GCC's behavior is considered correct. How clueless of me to miss such obvious fact. So it turns out that notify_all_at_thread_exit() does *not* have any bugs and can be used safely? I reverted the GCC workaround I had in my codebase. We can close the issue already. It was dumb of me to even assume that GCC could have bugs.
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Vinícius dos Santos Oliveira changed: What|Removed |Added CC||vini.ipsmaker at gmail dot com --- Comment #2 from Vinícius dos Santos Oliveira --- Created attachment 51126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51126&action=edit bugfix Here's a patch fixing the issue. If you want a codebase affected by the issue, here's the code for a thread joining detached threads through a condition variable: https://gitlab.com/emilua/emilua/-/blob/e5706426305733af02983ecb92a08dd8a00ebf2e/src/main.ypp#L275 Once the condition is met, both resources (mutex + condition variables) are destroyed just before the application exits. Therefore I cannot use notify_all_at_thread_exit (there would be a race there).
