Small update for an obvious compilation issue and to review new test 
case that could have lead to an infinite loop if the increment issue was 
not detected.

I also forgot to ask if there is more chance for the instantiation to be 
elided when it is implemented like in the _Safe_local_iterator:
return { __cur, this->_M_sequence };

than in the _Safe_iterator:
return _Safe_iterator(__cur, this->_M_sequence);

In the case where the user code do not use it ?

Fully tested now, ok to commit ?

François

On 11/01/23 07:03, François Dumont wrote:
> 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.