> ...
> This might be preventable if you can somehow arrange for the static
> constructors from a.so to run first.
Agreed. Yes, it is preventable. As I stated, this way of ´reproducing´
the problem is too artificial.
But what worries me is that in boost it is no preventable, at least
not easily, in the generic case -in this specific case the problem
does not arise using
LD_PRELOAD=/.../libboost_filesystem-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0.
*** In boost/system/error_code.hpp we can find
namespace boost { namespace system {
class error_category : public noncopyable {
/* no data members, the same can be said abaut noncopyable */
/* no declared ctors for error_category */
...
};
...
BOOST_SYSTEM_DECL const error_category & generic_category();
...
static const error_category & posix_category = generic_category();
...
}}
*** In boost/system/error_code.cpp we see
namespace boost { namespace system {
class generic_error_category : public error_category {
/* no data members */
/* no declared ctors */
...
};
....
BOOST_SYSTEM_DECL const error_category & generic_category() {
static const generic_error_category generic_category_const;
return generic_category_const;
}
....
}}
I inspect with nm. The generated constructor of class error_category
is present as a weak symbol in three boost shared objects:
boost.system, boost.thread and boost.filesystem.
What I really would like to verify is if my interpretation is correct.
My interpretation is that ld or ld.so make that boost.system shared
object static initialization calls error_category generated ctor
defined in boost.thread shared object and not the one defined locally
in the boost.system shared object.
It can be seen that boost.system shared object static initialization
in frames 35, 34, 44 and 32, calls boost::system::generic_category()
-frame 31- which seems to trigger boost.thread shared object load and
static initialization, which in turn opens pandora's box- ie.
reentrant call to boost::system::generic_category() in this case.
Note: I am conscious that It is not necessarily a problem of gcc, or
ld, or ld.so or boost. It may just be the fact that c++ do not mix
with shared object very well.
#0 0xfd459019 in __lwp_park () from /lib/libc.so.1
#1 0xfd45365e in cond_sleep_queue () from /lib/libc.so.1
#2 0xfd453817 in cond_wait_queue () from /lib/libc.so.1
#3 0xfd453b94 in cond_wait_common () from /lib/libc.so.1
#4 0xfd453d02 in _cond_wait () from /lib/libc.so.1
#5 0xfd453d2d in cond_wait () from /lib/libc.so.1
#6 0xfd453d66 in pthread_cond_wait () from /lib/libc.so.1
#7 0xfd632898 in __gthread_cond_wait (g=0xfd822ea8) at
/export/home/bcpp/mlevalle/work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:846
#8 __gthread_cond_wait_recursive (g=0xfd822ea8) at
/export/home/bcpp/mlevalle/work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:860
#9 __gnu_cxx::__cond::wait_recursive (g=0xfd822ea8) at
/export/home/bcpp/mlevalle/work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/ext/concurrence.h:377
#10 __cxa_guard_acquire (g=0xfd822ea8) at
../../../../src/gcc-4.6.2/libstdc++-v3/libsupc++/guard.cc:289
boost::system::generic_category(), although there is no reentrancy in
the c++ code.
#11 0xfd812313 in boost::system::generic_category () at
libs/system/src/error_code.cpp:425
#12 0xfe85cd38 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
./boost/system/error_code.hpp:214
#13 0xfe85d05f in _GLOBAL__sub_I_instantiate_re2c_lexer_str.cpp () at
libs/wave/src/instantiate_re2c_lexer_str.cpp:56
#14 0xfe8868fd in __do_global_ctors_aux () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#15 0xfe88692a in _init () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost/lib/libboost_wave-gcc46-
mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#16 0xfefce37e in call_init () from /usr/lib/ld.so.1
#17 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1
#18 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1
#19 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1
#20 0xfee60688 in ?? ()
#21 0xfee0c8f6 in
boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>()
at ./boost/exception/detail/exception_ptr.hpp:119
#22 0xfee0c0d2 in
__static_initialization_and_destruction_0(__initialize_p=1,
__priority=65535) at
./boost/exception/detail/exception_ptr.hpp:138
#23 0xfee0c271 in _GLOBAL__sub_I_future.cpp () at libs/thread/src/future.cpp:60
#24 0xfee0d98d in __do_global_ctors_aux () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost
/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#25 0xfee0d9ba in _init () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#26 0xfefce37e in call_init () from /usr/lib/ld.so.1
#27 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1
#28 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1
#29 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1
#30 0xfdce0688 in ?? ()
#31 0xfd81232a in boost::system::generic_category () at
libs/system/src/error_code.cpp:425
#32 0xfd812386 in
__static_initialization_and_destruction_0(__initialize_p=1,
__priority=65535) at ./boost/system/error_code.hpp:214
#33 0xfd8123ed in _GLOBAL__sub_I_error_code.cpp () at
libs/system/src/error_code.cpp:430
#34 0xfd8126ed in __do_global_ctors_aux () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#35 0xfd81271a in _init () from
/export/home/bcpp/jfranzoy/nuevorep/BCPP/Modulos/legacy/boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0
#36 0xfefce37e in call_init () from /usr/lib/ld.so.1
#37 0xfefcd7d5 in setup () from /usr/lib/ld.so.1
#38 0xfefdba3e in _setup () from /usr/lib/ld.so.1
#39 0xfefc299c in _rt_boot () from /usr/lib/ld.so.1
#40 0x08047540 in ?? ()
#41 0x08047670 in ?? ()
> Why are there two threads?
> Is it just a single thread, contained in a single LWP?
You are right
Thanks a lot
