From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 163F4385AC1C; Tue, 25 Jan 2022 14:52:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 163F4385AC1C From: "poulhies at adacore dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode Date: Tue, 25 Jan 2022 14:52:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: poulhies at adacore dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 14:52:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65343 Marc Poulhi=C3=A8s changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |poulhies at adacore dot com --- Comment #3 from Marc Poulhi=C3=A8s --- 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=C3=A7ois Dumont 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 fir= st called, during the construction of " __gnu_test::citerator<__gnu_debug::str= ing> dtest1;" in main(). #0 __gnu_cxx::__mutex::__mutex (this=3D0x801a80c0 <__gnu_internal::get_mutex(unsigned char)::m>) at ...libstdc++-v3/include/ext/concurrence.h:132 #1 0x0000000080043188 in __gnu_internal::M::M (this=3D0x801a80c0 <__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=3D5 '\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=3D0x800431ac <__tcf_0(void*)>, data=3D0x0, dso_handle=3D0x801a5d40) at cxa_atexit.c:215 #1 0x0000000080043290 in __gnu_internal::get_mutex (i=3D5 '\005') at .../libstdc++-v3/src/c++11/shared_ptr.cc:39 #2 0x0000000080010710 in (anonymous namespace)::get_safe_base_mutex (address=3D0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string, std::allocator > >::_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=3D0x801a8480 <__gnu_internal::get_mutex(uns= igned char)::m+960>, __in_chrg=3D) 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=3D0x0) at cxa_atexit.c= :222 #3 0x00000000800f4cac in __do_atexit_work () at cxa_atexit.c:229 #4 0x00000000800ff274 in exit (status=3D0) at vxexit.c:49 #5 0x00000000800001d8 in _start () A later destructor for the _S_container object then tries to lock the destr= oyed and now invalid mutexes, leading to an error. #0 __gnu_cxx::__mutex::lock (this=3D0x801a8200 <__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=3D0x600e68, __name=3D...) at ...p/libstdc++-v3/include/ext/concurrenc= e.h:241 #2 0x00000000800109c4 in __gnu_debug::_Safe_sequence_base::_M_detach_all (this=3D0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string, std::allocator > >::_S_container>) at .../libstdc++-v3/src/c++11/debug.cc:255 ... #7 0x00000000800f4ae4 in __cxa_finalize (dso_handle=3D0x0) at cxa_atexit.c= :222 #8 0x00000000800f4cac in __do_atexit_work () at cxa_atexit.c:229 #9 0x00000000800ff274 in exit (status=3D0) 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.=