[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2006-10-07 18:56 -------
Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites

> ------- Comment #16 from bkoz at gcc dot gnu dot org  2006-10-06 09:52 -------
> When you get to "break here" this is what your mutex should look like in gdb:

Well, we don't actually get to "break here".  The program hangs in
xactly the same way as 23591_thread-1:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x4010ee00) at mutex.c:99
#1  0x400679e4 in locale (this=0x4010dae4)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:549
#2  0x40062984 in Init (this=<value optimized out>)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/streambuf:462
#3  0x4007ca28 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=0)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/iostream:77
#4  0x400eb140 in __do_global_ctors_aux ()
    from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5  0x40051924 in _init ()
    from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
...
(gdb) p *mutex
$9 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) p &locale_mutex
$10 = (__gnu_cxx::__mutex *) 0x4010ee00
(gdb) p mutex
$11 = (pthread_mutex_t *) 0x4010ee00

As can be seen, this occurs running constructors from _init ().  There
are several other calls to __GI___pthread_mutex_lock with properly
initialized mutexes prior to the one shown above which isn't properly
initialized.  A properly initialized mutex looks like:

(gdb) p *mutex
$13 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

There are two earlier calls to __GI___pthread_mutex_lock from locale.
The first is here:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x402e1cb0) at mutex.c:99
#1  0x402ca258 in __pthread_once (once_control=0x4010dff8,
    init_routine=@0x4010bf52: 0x40067568 <std::locale::_S_initialize_once()>)
    at mutex.c:301
#2  0x40067620 in std::locale::_S_initialize ()
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:516
#3  0x4006797c in locale (this=0x402e1cb0)
    at ../../../../gcc/libstdc++-v3/src/locale_init.cc:209
...

(gdb) info symbol 0x402e1cb0
once_masterlock in section .data
(gdb) p mutex
$14 = (pthread_mutex_t *) 0x402e1cb0
(gdb) p *mutex
$15 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

once_masterlock appears to be statically initialized.

>From locale_init.cc:

  locale::locale() throw() : _M_impl(0)
    {
      _S_initialize();
      __gnu_cxx::__scoped_lock sentry(locale_mutex);
      _S_global->_M_add_reference();
      _M_impl = _S_global;
    }

It appears we hang at the "once_masterlock" line.  We never get to
the next line.

Dave


-- 


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