mysterious hang in pthread_create

[Andriy Gapon]

I've got quite a strange issue with only one particular threaded program.

My system is 7-STABLE from around July 6 (rather old, I know).
I, of course, use libthr as a thread library.
I have plenty of threaded programs and all of them except one are 
working perfectly (firefox, thunderbird, KDE).

The bad one is linuxdcpp (net-p2p/linuxdcpp, linuxdcpp-1.0.2).
I built it with debug enabled and also rebuilt libthr with debug.
It seems that the program hangs in the very first call to pthread_create.

Here's a stack trace of the hanging program:
#0  _thr_umtx_wait (mtx=0x838774c, id=0, timeout=0x0) at 
/system/src/lib/libthr/thread/thr_umtx.c:93
#1  0x28f9168c in _thr_rtld_rlock_acquire (lock=0x8387740) at 
/system/src/lib/libthr/thread/thr_rtld.c:129
#2  0x282a6a27 in dlopen () from /libexec/ld-elf.so.1
#3  0x282a491d in dladdr () from /libexec/ld-elf.so.1
#4  0x282a1469 in ?? () from /libexec/ld-elf.so.1
#5  0x289b3600 in ?? ()
#6  0x000000d8 in ?? ()
#7  0x000186d1 in ?? ()
#8  0x00000000 in ?? ()
#9  0x08303a00 in ?? ()
#10 0x00000246 in ?? ()
#11 0x289b3600 in ?? ()
#12 0x000000d8 in ?? ()
#13 0x28f94b5f in _tcb_ctor (thread=0x8303a00, initial=0) at 
/system/src/lib/libthr/arch/i386/i386/pthread_md.c:46
#14 0x28f94215 in _thr_alloc (curthread=0x8302100) at 
/system/src/lib/libthr/thread/thr_list.c:169
#15 0x28f8d22e in _pthread_create (thread=0x831cb90, attr=0x0, 
start_routine=0x8170ce0 <Thread::starter(void*)>, arg=0x831cb8c)
     at /system/src/lib/libthr/thread/thr_create.c:68
#16 0x08170bd8 in Thread::start (this=0x831cb8c) at client/Thread.cpp:41
#17 0x080abfb4 in HashManager::startup (this=0x831cb60) at HashManager.h:97
#18 0x0809f4d6 in startup (f=0x827a2c0 <callBack(void*, std::string 
const&)>, p=0x0) at client/DCPlusPlus.cpp:82
#19 0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61

I tracked all calls to functions of _thr_rtld_*lock* family and it seems 
that the lock in question gets acquired for writing before the above 
access. The stack:
#0  _thr_rtld_wlock_acquire (lock=0x8387740) at 
/system/src/lib/libthr/thread/thr_rtld.c:144
#1  0x282a6dcc in _rtld_thread_init () from /libexec/ld-elf.so.1
#2  0x28f91af6 in _thr_rtld_init () at 
/system/src/lib/libthr/thread/thr_rtld.c:238
#3  0x28f938db in _thr_setthreaded (threaded=1) at 
/system/src/lib/libthr/thread/thr_kern.c:56
#4  0x28f8d208 in _pthread_create (thread=0x831cb90, attr=0x0, 
start_routine=0x8170ce0 <Thread::starter(void*)>, arg=0x831cb8c)
     at /system/src/lib/libthr/thread/thr_create.c:64
#5  0x08170bd8 in Thread::start (this=0x831cb8c) at client/Thread.cpp:41
#6  0x080abfb4 in HashManager::startup (this=0x831cb60) at HashManager.h:97
#7  0x0809f4d6 in startup (f=0x827a2c0 <callBack(void*, std::string 
const&)>, p=0x0) at client/DCPlusPlus.cpp:82
#8  0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61

It seems that for all other programs there is no such call as the above 
( I mean wlock_acquire).
I didn't have debug symbols in rtld when I executed this test, 
unfortunately.

The problem is 100% reproducible, so I can get any additional debugging 
info.
I wonder what can be so special about this program, what can be going 
wrong. I didn't quite get the logic with flags and masks in 
_rtld_thread_init (especially when lockinfo is still default, but the 
issue seems to be related to that.

-- 
Andriy Gapon