From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23573 invoked by alias); 26 Sep 2005 23:22:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 23546 invoked by uid 48); 26 Sep 2005 23:22:08 -0000 Date: Mon, 26 Sep 2005 23:22:00 -0000 From: "bkoz at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20050926232200.24071.bkoz@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/24071] New: solaris vs. __gthread_active_p X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg03134.txt.bz2 List-Id: The patch for 22309 kills Solaris 2.6, 2.7, 2.8, and 2.9. The failure mode is as follows: FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test FAIL: ext/mt_allocator/check_delete.cc execution test FAIL: ext/mt_allocator/check_new.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test FAIL: ext/mt_allocator/tune-1.cc execution test FAIL: ext/mt_allocator/tune-2.cc execution test FAIL: ext/mt_allocator/tune-3.cc execution test FAIL: ext/mt_allocator/tune-4.cc execution test And can be seen here: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01189.html Eric Botcazou provided the following commentary in private email: backtrace at -O0: Program received signal SIGSEGV, Segmentation fault. 0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac, __bytes=40) at ext/mt_allocator.h:146 146 { return _M_binmap[__bytes]; } (gdb) bt #0 0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac, __bytes=40) at ext/mt_allocator.h:146 #1 0x0001d7fc in __gnu_cxx::__mt_alloc >::allocate (this=0xffbefa3e, __n=10) at ext/mt_allocator.h:674 #2 0x0001d940 in __gnu_test::check_new<__gnu_cxx::__mt_alloc >, true> (a=@0xffbefa3e) at testsuite_allocator.h:187 #3 0x0001d9cc in test01 () at /home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:49 #4 0x0001da7c in main () at /home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:54 (gdb) p _M_binmap $1 = (short unsigned int *) 0x0 I put 3 breakpoints in mt_allocator.cc and _M_binmap is never initialized, as __gnu_cxx::__common_pool_base<__gnu_cxx::__pool, true>::_S_initialize() is never called. The problem stems from: static void _S_initialize_once() { static bool __init; if (__builtin_expect(__init == false, false)) { if (__gthread_active_p()) { // On some platforms, __gthread_once_t is an aggregate. static __gthread_once_t __once = __GTHREAD_ONCE_INIT; __gthread_once(&__once, _S_initialize); } else _S_get_pool()._M_initialize_once(); __init = true; } } __gthread_once never calls _S_initialize on Solaris 7, 8, 9, while it does on Solaris 10. This boils down to the following lines in the manual: " These switches are supported in addition to the above on Solaris: `-threads' Add support for multithreading using the Solaris threads library. This option sets flags for both the preprocessor and linker. This option does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. `-pthreads' Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. This option does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it." You need to pass -pthreads to the compiler to make the thing work. More: No, pthread_cancel is defined because it is present in the libc: gax% nm -pl /lib/libc.so.1 | grep pthread_cancel 0000634812 T* _pthread_cancel 0000634812 T* pthread_cancel gax% nm -pl /lib/libpthread.so.1 | grep pthread_cancel 0000015516 T _pthread_cancel 0000015516 T* pthread_cancel Same for pthread_once: gax% nm -pl /lib/libc.so.1 | grep pthread_once 0000635324 T* _pthread_once 0000635324 T* pthread_once gax% nm -pl /lib/libpthread.so.1 | grep pthread_once 0000015476 T _pthread_once 0000015476 T* pthread_once But the latter is probably a dummy function because: Reformatting page. Please Wait... done Threads Library Functions pthread_once(3THR) NAME pthread_once - initialize dynamic package [...] NOTES Solaris threads do not offer this functionality. SunOS 5.8 Last change: 2 Jun 1998 2 The situation is different on Solaris 10 because all the functions in the pthreads library are only placeholders for the libc functions: hikaru% nm -pl /lib/libpthread.so.1 | grep pthread_cancel 0000000000 T _pthread_cancel 0000000000 T pthread_cancel hikaru% nm -pl /lib/libc.so.1 | grep pthread_cancel 0000703188 T _pthread_cancel 0000703188 T* pthread_cancel ... thus leading to the odd behavior where __gthread_active_p is true, but __gthread_once doesn't run the "once" function, and yet returns zero. It looks like this has been an issue in past versions of the mt_allocator.h code, in that initialization was forced after the gthread_once call. This was confusing, but apparently necessary due to the tricky gthread_once issue. Possible solutions: 1) force double initialization again. 2) add dg-options "-pthread" for solaris on the given testsuite files 3) link libstdc++ builds on solaris with -pthread. Libjava already does this. See see libjava/configure.ac:759. 4) fix __gthread_active_p on solaris to make it work like other systems. -- Summary: solaris vs. __gthread_active_p Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071