[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Leon suggested using the _M_sequence pointer to access the mutex pool directly,
instead of calling _M_sequence->_M_get_mutex() (which is undefined if
_M_sequence is being destroyed).

Combining that with some atomic ops and a double-checked lock might be good
enough:

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -381,10 +381,10 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_detach()
   {
-    if (_M_sequence)
+    if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
       {
-       _M_sequence->_M_detach(this);
-       _M_reset();
+       __gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
+       _M_detach_single();
       }
   }

@@ -403,7 +403,7 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_reset() throw ()
   {
-    _M_sequence = 0;
+    __atomic_store_n(&_M_sequence, (_Safe_sequence_base*)0, __ATOMIC_RELEASE);
     _M_version = 0;
     _M_prior = 0;
     _M_next = 0;


This fixes the ThreadSanitizer errors for the provided testcase.

One problem with this approach is that not all targets support pointer-width
atomics without linking to libatomic.