[Bug libstdc++/24071] solaris vs. __gthread_active_p

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at libertysurf dot
                   |                            |fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] New: solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

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<unsigned int, 
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate 
(this=0xffbefa3e, __n=10)
    at ext/mt_allocator.h:674
#2  0x0001d940 in __gnu_test::check_new<__gnu_cxx::__mt_alloc<unsigned int, 
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >, 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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2005-09-26 23:24 -------
Created an attachment (id=9815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9815&action=view)
double intialization patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9815|double intialization patch  |force intialization patch
        description|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-09-27 07:14 -------
> 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.

I think we need to do both 3) [but again libjava is not built with -pthreads, it
is *linked* against -lpthread and on *all* platforms] and 4).


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-09-27 07:14:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-10-01 08:53 -------
I'm confused about the status of this bug.  I believe it is fixed on the 4.0
branch (originally for 4.0.2, but due to the release both, actually for 4.0.3).
 However, this bug is still marked as "New".  If the problem is fixed, please
close the PR.

Thanks,

-- Mark

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-10-01 09:02 -------
> I'm confused about the status of this bug.  I believe it is fixed on the 4.0
> branch (originally for 4.0.2, but due to the release both, actually for 4.0.3).
>  However, this bug is still marked as "New".  If the problem is fixed, please
> close the PR.

The fix is more of a workaround around the peculiarity of __gthread_active_p on
Solaris (duality Solaris/POSIX threads) than a fix, so I think the PR should be
kept open and the target milestone probably not set to 4.0.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-10-01 09:17 -------
OK, I have unset the target milestone.

Thanks,

-- Mark

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-09-27 07:14:13         |2005-10-01 18:45:54
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2005-10-01 18:50 -------

Hey dudes. 

Mark, the original problem report, the fails, is fixed on mainline and on the
gcc-4_0-branch. It looks like the fix for this, after all our effort, did not
make it into 4.0.2. Whoops: mistakes happen. I didn't consider this stop-ship
then and certainly don't now, and think that the notes Eric made (use -pthreads
if using __mt_allocator) are an acceptable workaround.

However, there is a bigger issue involved, which is still in progress. Actually,
I'd like to broaden this out a bit since it looks like we are thinking of
solving a related issue on linux as well. (See RH bugzilla, link below)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165728

Therefore, I'm suggesting I close this, and open a more general enhancement bug.

That might clarify the situation for everybody.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 19:41 -------
(In reply to comment #6)
> However, there is a bigger issue involved, which is still in progress. Actually,
> I'd like to broaden this out a bit since it looks like we are thinking of
> solving a related issue on linux as well. (See RH bugzilla, link below)
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165728

And this has been a bug for a long time in the FSF GCC, PR 4372.
I don't think there is an easy solution other than fixing glibc, just ot be thread by default and not have 
libpthread.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071