I've found a similar deadlock in my series of shared libraries. I
managed to get a backtrace from gdb which implicates a mutex lock in
gcc3/libstdc++/src/locale.cc:287 (const locale& locale::classic() {})
It appears that my libraries are causing a reentrancy on the locale()
initializer. locale is the only libstdc++ class to use a mutex at all.
Darn C++. It's got no firm semantics for when or how static
initializers are supposed to be executed w.r.t. dynamic libraries.
Technically, this is legal, however detrimental to our application.
(Line numbers below are because gdb is getting no debug info from
libstdc++, and is using the info from my code).
#0 0x90034f28 in semaphore_wait_trap ()
#1 0x9000a418 in pthread_mutex_lock ()
#2 0x052a0d80 in std::locale::classic() () at PP_Indent.cc:175
#3 0x052a05dc in std::locale::locale() () at PP_Indent.cc:175
#4 0x05294bd8 in std::basic_filebuf<char, std::char_traits<char>
>::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () at
PP_Indent.cc:175
#5 0x0529e9e4 in std::ios_base::Init::_S_ios_create(bool) () at
PP_Indent.cc:175
#6 0x0529ed68 in std::ios_base::Init::Init() () at PP_Indent.cc:175
#7 0x053aa01c in __static_initialization_and_destruction_0(int, int) ()
#8 0x053aa080 in
_GLOBAL__I__ZN5VData5VTypeIbLNS_14CollectionTypeE0EE4typeE ()
#9 0x8fe16350 in __dyld_call_module_initializers_for_library ()
#10 0x8fe160e4 in __dyld_call_module_initializers ()
#11 0x8fe106f0 in __dyld_link_in_need_modules ()
#12 0x8fe1016c in __dyld_bind_lazy_symbol_reference ()
#13 0x8fe00ec0 in __dyld_stub_binding_helper_interface ()
#14 0x052a0dd8 in std::locale::classic() () at PP_Indent.cc:175
#15 0x052a05dc in std::locale::locale() () at PP_Indent.cc:175
#16 0x05294bd8 in std::basic_filebuf<char, std::char_traits<char>
>::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () at
PP_Indent.cc:175
#17 0x0529e9e4 in std::ios_base::Init::_S_ios_create(bool) () at
PP_Indent.cc:175
#18 0x0529ed68 in std::ios_base::Init::Init() () at PP_Indent.cc:175
#19 0x053a9f1c in __static_initialization_and_destruction_0(int, int) ()
#20 0x053a9f80 in _GLOBAL__I__ZN5VData3Tmp13alter_versionEPK2VGPS_i ()
#21 0x8fe16350 in __dyld_call_module_initializers_for_library ()
#22 0x8fe160e4 in __dyld_call_module_initializers ()
#23 0x8fe106f0 in __dyld_link_in_need_modules ()
#24 0x8fe1016c in __dyld_bind_lazy_symbol_reference ()
#25 0x8fe00ec0 in __dyld_stub_binding_helper_interface ()
#26 0x05294bd8 in std::basic_filebuf<char, std::char_traits<char>
>::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () at
PP_Indent.cc:175
#27 0x0529e9e4 in std::ios_base::Init::_S_ios_create(bool) () at
PP_Indent.cc:175
#28 0x0529ed68 in std::ios_base::Init::Init() () at PP_Indent.cc:175
#29 0x053a9d94 in __static_initialization_and_destruction_0(int, int) ()
#30 0x053a9e80 in _GLOBAL__I_system_vg ()
#31 0x8fe16350 in __dyld_call_module_initializers_for_library ()
#32 0x8fe160e4 in __dyld_call_module_initializers ()
#33 0x8fe106f0 in __dyld_link_in_need_modules ()
#34 0x8fe102d0 in __dyld_bind_lazy_symbol_reference ()
#35 0x8fe00ec0 in __dyld_stub_binding_helper_interface ()
#36 0x0182e914 in single_client_gc_alloc_template<0>::allocate(unsigned
long) ()
#37 0x0182e270 in
gc_typed_allocator<__gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage
const* const, _jobject*> >*>::allocate(unsigned long, void const*) ()
#38 0x0182dbf0 in
std::_Vector_alloc_base<__gnu_cxx::_Hashtable_node<std::pair<AbstractLan
guage const* const, _jobject*> >*, gc_allocator,
false>::_M_allocate(unsigned long) ()
#39 0x0182c3bc in __gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage
const* const, _jobject*> >*
std::vector<__gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage
const* const, _jobject*> >*,
gc_allocator>::_M_allocate_and_copy<__gnu_cxx::_Hashtable_node<std::pair
<AbstractLanguage const* const, _jobject*> >**>(unsigned long,
__gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage const* const,
_jobject*> >**, __gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage
const* const, _jobject*> >**) ()
#40 0x0182c1e8 in
std::vector<__gnu_cxx::_Hashtable_node<std::pair<AbstractLanguage
const* const, _jobject*> >*, gc_allocator>::reserve(unsigned long) ()
#41 0x0182c0b0 in __gnu_cxx::hashtable<std::pair<AbstractLanguage
const* const, _jobject*>, AbstractLanguage const*,
hash<AbstractLanguage const*>,
std::_Select1st<std::pair<AbstractLanguage const* const, _jobject*> >,
equal_to<AbstractLanguage const*>,
gc_allocator>::_M_initialize_buckets(unsigned long) ()
#42 0x0182bf00 in __gnu_cxx::hashtable<std::pair<AbstractLanguage
const* const, _jobject*>, AbstractLanguage const*,
hash<AbstractLanguage const*>,
std::_Select1st<std::pair<AbstractLanguage const* const, _jobject*> >,
equal_to<AbstractLanguage const*>, gc_allocator>::hashtable(unsigned
long, hash<AbstractLanguage const*> const&, equal_to<AbstractLanguage
const*> const&, gc_typed_allocator<std::pair<AbstractLanguage const*
const, _jobject*> > const&) ()
#43 0x0182be34 in __gnu_cxx::hashtable<std::pair<AbstractLanguage
const* const, _jobject*>, AbstractLanguage const*,
hash<AbstractLanguage const*>,
std::_Select1st<std::pair<AbstractLanguage const* const, _jobject*> >,
equal_to<AbstractLanguage const*>, gc_allocator>::hashtable(unsigned
long, hash<AbstractLanguage const*> const&, equal_to<AbstractLanguage
const*> const&, gc_typed_allocator<std::pair<AbstractLanguage const*
const, _jobject*> > const&) ()
#44 0x0182bd90 in __gnu_cxx::hash_map<AbstractLanguage const*,
_jobject*, hash<AbstractLanguage const*>, equal_to<AbstractLanguage
const*>, gc_allocator>::hash_map() ()
#45 0x0182bd2c in __gnu_cxx::hash_map<AbstractLanguage const*,
_jobject*, hash<AbstractLanguage const*>, equal_to<AbstractLanguage
const*>, gc_allocator>::hash_map() ()
#46 0x01893124 in __static_initialization_and_destruction_0(int, int) ()
#47 0x018931b4 in _GLOBAL__I_native_langs ()
#48 0x8fe16594 in __dyld_call_module_initializers_for_objects ()
#49 0x8fe160a0 in __dyld_call_module_initializers ()
#50 0x8fe106f0 in __dyld_link_in_need_modules ()
#51 0x8fe12230 in __dyld__dyld_link_module ()
#52 0x900171c8 in NSLinkModule ()
On Friday, August 16, 2002, at 10:53 AM, Stuart Hastings wrote:
>
> On Friday, Aug 16, 2002, at 10:23 US/Pacific, Galen Faidley wrote:
>
>> I hope this is the correct list to send my question to. I couldn't
>> find the page dedicated to the list on apples site so I couldn't read
>> the description, archives, or even join the list.
>>
>> I am using the version of gcc3 that came with the April developer
>> tools:
>> Apple Computer, Inc. GCC version 1041, based on gcc version 3.1
>> 20020105 (experimental)
>>
>> I am experiencing problems with dynamic linking. The problems
>> manifest themselves on runtime. When the first call to a function in
>> my library is made the application gets stuck in a
>> semaphore_wait_trap () . There is only one thread running so of
>> course it will never get out of the trap. I may very well have built
>> my library incorrectly
>> (is there some documentation on how it should be done?)
>
> There may be, but offhand I don't know where.
>
> Try pasting this into your WWW browser:
>
> file:///Developer/Documentation/DeveloperTools/devtools.html
>
> This may also be helpful:
>
> file:///Developer/Documentation/DeveloperTools/libtool/
> libtool_toc.html
>
> Both of these docs are standard parts of the imminent Jaguar release;
> alas, I don't have a Puma system handy to make sure they're in the
> same places. If you don't find them right off, ask Sherlock (or UNIX
> 'find') to look for you.
>
>> but I get no error when building the library or building the app. If
>> I link my application statically everything behaves as it should.
>
> I'm sorry I can't do more for you right now. Our linker expert is on
> vacation for another week.
>
> stuart hastings
>
>
-----------
Andrew Begel
Ph.D. Candidate
Computer Science Division
University of California, Berkeley
