public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99613] Static variable destruction order race condition Date: Tue, 20 Apr 2021 23:33:30 +0000 [thread overview] Message-ID: <bug-99613-4-LKkfbI5AfY@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99613-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613 --- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-9 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:cb6efb9d909323e41fa0a8abbe805eb32d1659ea commit r9-9432-gcb6efb9d909323e41fa0a8abbe805eb32d1659ea Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Mar 16 21:17:44 2021 +0100 c++: Ensure correct destruction order of local statics [PR99613] As mentioned in the PR, if end of two constructions of local statics is strongly ordered, their destructors should be run in the reverse order. As we run __cxa_guard_release before calling __cxa_atexit, it is possible that we have two threads that access two local statics in the same order for the first time, one thread wins the __cxa_guard_acquire on the first one but is rescheduled in between the __cxa_guard_release and __cxa_atexit calls, then the other thread is scheduled and wins __cxa_guard_acquire on the second one and calls __cxa_quard_release and __cxa_atexit and only afterwards the first thread calls its __cxa_atexit. This means a variable whose completion of the constructor strongly happened after the completion of the other one will be destructed after the other variable is destructed. The following patch fixes that by swapping the __cxa_guard_release and __cxa_atexit calls. 2021-03-16 Jakub Jelinek <jakub@redhat.com> PR c++/99613 * decl.c (expand_static_init): For thread guards, call __cxa_atexit before calling __cxa_guard_release rather than after it. Formatting fixes. (cherry picked from commit 1703937a05b8b95bc29d2de292387dfd9eb7c9a3)
next prev parent reply other threads:[~2021-04-20 23:33 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-16 10:58 [Bug c++/99613] New: " michalz at nvidia dot com 2021-03-16 11:42 ` [Bug c++/99613] " rguenth at gcc dot gnu.org 2021-03-16 12:23 ` jakub at gcc dot gnu.org 2021-03-16 12:35 ` jakub at gcc dot gnu.org 2021-03-16 12:37 ` michalz at nvidia dot com 2021-03-16 12:42 ` jakub at gcc dot gnu.org 2021-03-16 12:48 ` rguenth at gcc dot gnu.org 2021-03-16 12:56 ` jakub at gcc dot gnu.org 2021-03-16 13:04 ` michalz at nvidia dot com 2021-03-16 13:07 ` michalz at nvidia dot com 2021-03-16 13:15 ` jakub at gcc dot gnu.org 2021-03-16 13:24 ` michalz at nvidia dot com 2021-03-16 13:25 ` michalz at nvidia dot com 2021-03-16 13:35 ` jakub at gcc dot gnu.org 2021-03-16 14:05 ` michalz at nvidia dot com 2021-03-16 14:07 ` jacobhemstad at gmail dot com 2021-03-16 14:23 ` jakub at gcc dot gnu.org 2021-03-16 14:38 ` rguenth at gcc dot gnu.org 2021-03-16 20:18 ` cvs-commit at gcc dot gnu.org 2021-03-19 23:30 ` cvs-commit at gcc dot gnu.org 2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org [this message] 2021-04-22 16:51 ` cvs-commit at gcc dot gnu.org 2021-04-22 17:10 ` jakub at gcc dot gnu.org 2021-09-11 14:22 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99613-4-LKkfbI5AfY@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).