[Bug libstdc++/108861] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[Bug libstdc++/108861] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[vini.ipsmaker at gmail dot com]

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++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Isn't this just Bug 98449? Why did you close that as FIXED?

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[vini.ipsmaker at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

--- Comment #2 from Vinícius dos Santos Oliveira <vini.ipsmaker at gmail dot com> ---
> 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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vinícius dos Santos Oliveira from comment #2)
> > 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.

Because there is an open defect report against the C++ standard about this.
Basically until that is resolved, GCC's behavior is considered correct.

*** This bug has been marked as a duplicate of bug 98449 ***

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Vinícius dos Santos Oliveira from comment #2)
> 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.

Opening a duplicate of it doesn't change anything.

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[vini.ipsmaker at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

--- Comment #5 from Vinícius dos Santos Oliveira <vini.ipsmaker at gmail dot com> ---
> 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++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Nobody said there's no bug, that's why your previous bug report was suspended,
not closed as invalid. The point is that what GCC does today conforms to the
standard. If there's a bug in the standard, it should be fixed in the standard,
and then GCC will follow. There's no need to be a sarcastic prat about it.