Thanks for fixing this.

Here is the extension of the fix to all post-increment/decrement 
operators we have on _GLIBCXX_DEBUG iterator.

I prefer to restore somehow previous implementation to continue to have 
_GLIBCXX_DEBUG post operators implemented in terms of normal post operators.

I also plan to remove the debug check in the _Safe_iterator constructor 
from base iterator to avoid the redundant check we have now. But I need 
to make sure first that we are never calling it with an unchecked base 
iterator. And it might not be the right moment to do such a change.

     libstdc++: Fix deadlock in debug local_iterator increment [PR108288]

     Complete fix on all _Safe_iterator post-increment and 
post-decrement implementations
     and on _Safe_local_iterator.

     libstdc++-v3/ChangeLog:

             * include/debug/safe_iterator.h 
(_Safe_iterator<>::operator++(int)): Extend deadlock fix to
             other iterator category.
             (_Safe_iterator<>::operator--(int)): Likewise.
             * include/debug/safe_local_iterator.h 
(_Safe_local_iterator<>::operator++(int)): Fix deadlock.
             * testsuite/util/debug/unordered_checks.h 
(invalid_local_iterator_pre_increment): New.
             (invalid_local_iterator_post_increment): New.
             * 
testsuite/23_containers/unordered_map/debug/invalid_local_iterator_post_increment_neg.cc:
             New test.
             * 
testsuite/23_containers/unordered_map/debug/invalid_local_iterator_pre_increment_neg.cc:
             New test.

Tested under Linux x86_64.

Ok to commit ?

François

On 06/01/23 12:54, Jonathan Wakely via Libstdc++ wrote:
> Tested x86_64-linux. Pushed to trunk.
>
> I think we should backport this too, after some soak time on trunk.
>
> -- >8 --
>
> With -fno-elide-constructors the debug iterator post-increment and
> post-decrement operators are susceptible to deadlock. They take a mutex
> lock and then return a temporary, which also attempts to take a lock to
> attach itself to the sequence. If the return value and *this happen to
Note that the chosen mutex depends on the sequence so there is no need 
for conditional sentense here, it will necessarily be the same mutex.
> collide and use the same mutex from the pool, then you get a deadlock
> trying to lock a mutex that is already held by the current thread.