On 03/03/20 22:11 +0100, François Dumont wrote:
After the fix of PR 91910 I tried to consider other possible race
condition and I think we still have a problem.
Like stated in the PR when a container is destroyed all associated
iterators are made singular. If at the same time another thread try to
access this iterator the _M_singular check will face a data race when
accessing _M_sequence member. In case of race condition the program is
likely to abort but maybe because of memory access violation rather
than a clear singular iterator assertion.
To avoid this I rework _M_sequence manipulation to use atomic read
when necessary and make sure that otherwise container mutex is locked.
* src/c++/debug.cc
(_Safe_sequence_base::_M_attach_single): Set attached iterator
sequence pointer and version.
(_Safe_sequence_base::_M_detach_single): Reset detached
iterator.
(_Safe_iterator_base::_M_attach): Remove attached iterator
sequence
pointer and version assignments.
(_Safe_iterator_base::_M_attach_single): Likewise.
(_Safe_iterator_base::_M_detach_single): Remove detached
iterator
reset.
(_Safe_iterator_base::_M_singular): Use atomic load to
access parent
sequence.
(_Safe_iterator_base::_M_can_compare): Likewise.
(_Safe_iterator_base::_M_get_mutex): Likewise.
(_Safe_local_iterator_base::_M_attach): Remove attached
iterator container
pointer and version assignments.
(_Safe_local_iterator_base::_M_attach_single): Likewise.
(_Safe_unordered_container_base::_M_attach_local_single):
Set attached iterator container pointer and version.
(_Safe_unordered_container_base::_M_detach_local_single): Reset detached
iterator.
Running tests in Debug mode.
Ok to commit if successful ?
I don't think we want to change this so close to the end of the GCC 10
cycle. Let's revisit it in a few weeks.
