[Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode

["poulhies at adacore dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Marc Poulhiès <poulhies at adacore dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |poulhies at adacore dot com

--- Comment #3 from Marc Poulhiès <poulhies at adacore dot com> ---
Hi !

It looks like we are seeing this issue using vxworks7 on gcc-11.

The test "/testsuite/21_strings/basic_string/requirements/citerators.cc" has
been updated since gcc-10 to use __gnu_debug::string:

8<----8<-----8<-----8<-----8<-----8<------
commit 50bb46e4d2543f2a78f97feddcde27e42639dae1
Author: François Dumont <fdumont@gcc.gnu.org>
Date:   Fri Mar 5 18:50:22 2021 +0100

    libstdc++: Fix and complete __gnu_debug::basic_string implementation
8<----8<-----8<-----8<-----8<-----8<------

Currently, the mutexes are created when  __gnu_internal::get_mutex() is first
called, during the construction of " __gnu_test::citerator<__gnu_debug::string>
dtest1;" in main().

#0  __gnu_cxx::__mutex::__mutex (this=0x801a80c0
<__gnu_internal::get_mutex(unsigned char)::m>) at
...libstdc++-v3/include/ext/concurrence.h:132
#1  0x0000000080043188 in __gnu_internal::M::M (this=0x801a80c0
<__gnu_internal::get_mutex(unsigned char)::m>) at
.../libstdc++-v3/src/c++11/shared_ptr.cc:38
#2  0x0000000080043268 in __gnu_internal::get_mutex (i=5 '\005') at
.../libstdc++-v3/src/c++11/shared_ptr.cc:39
...
#14 0x00000000800005b8 in main () at
.../libstdc++-v3/testsuite/21_strings/basic_string/requirements/citerators.cc:29

On vxworks, __GTHREAD_MUTEX_INIT is not defined, so a destructor is defined for
the __mutex object (include/ext/concurrence.h:136) and registered with
__cxa_atexit.

#0  __cxa_atexit (fn=0x800431ac <__tcf_0(void*)>, data=0x0,
dso_handle=0x801a5d40) at cxa_atexit.c:215
#1  0x0000000080043290 in __gnu_internal::get_mutex (i=5 '\005') at
.../libstdc++-v3/src/c++11/shared_ptr.cc:39
#2  0x0000000080010710 in (anonymous namespace)::get_safe_base_mutex
(address=0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::_S_container>)
    at .../libstdc++-v3/src/c++11/debug.cc:66

Then, when main() returns, these mutexes' destructors are called, which on
vxworks call semDestroy() that invalidate the mutexes.

#0  __gnu_internal::M::~M (this=0x801a8480 <__gnu_internal::get_mutex(unsigned
char)::m+960>, __in_chrg=<optimized out>) at
.../libstdc++-v3/src/c++11/shared_ptr.cc:38
#1  0x00000000800431e0 in __tcf_0 () at
.../libstdc++-v3/src/c++11/shared_ptr.cc:39
#2  0x00000000800f4ae4 in __cxa_finalize (dso_handle=0x0) at cxa_atexit.c:222
#3  0x00000000800f4cac in __do_atexit_work () at cxa_atexit.c:229
#4  0x00000000800ff274 in exit (status=0) at vxexit.c:49
#5  0x00000000800001d8 in _start ()

A later destructor for the _S_container object then tries to lock the destroyed
and now invalid mutexes, leading to an error.

#0  __gnu_cxx::__mutex::lock (this=0x801a8200
<__gnu_internal::get_mutex(unsigned char)::m+320>)
    at .../libstdc++-v3/include/ext/concurrence.h:149
#1  0x0000000080000b1c in __gnu_cxx::__scoped_lock::__scoped_lock
(this=0x600e68, __name=...) at ...p/libstdc++-v3/include/ext/concurrence.h:241
#2  0x00000000800109c4 in __gnu_debug::_Safe_sequence_base::_M_detach_all
(this=0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::_S_container>)
    at .../libstdc++-v3/src/c++11/debug.cc:255
...
#7  0x00000000800f4ae4 in __cxa_finalize (dso_handle=0x0) at cxa_atexit.c:222
#8  0x00000000800f4cac in __do_atexit_work () at cxa_atexit.c:229
#9  0x00000000800ff274 in exit (status=0) at vxexit.c:49
#10 0x00000000800001d8 in _start ()

Forcing a call to get_mutex() earlier during the _Safe_sequence_base ctor
forces the mutex destructor to be called in the correct order, but does not
seem like a very robust workaround.