mysterious hang in pthread_create

David Xu davidxu at freebsd.org
Tue Sep 2 01:36:38 UTC 2008


Kostik Belousov wrote:
> On Mon, Sep 01, 2008 at 03:17:46PM +0300, Andriy Gapon wrote:
>> on 01/09/2008 14:12 Kostik Belousov said the following:
>>> On Mon, Sep 01, 2008 at 01:53:23PM +0300, Andriy Gapon wrote:
> ...
>>>>>>> The following silly patch fixes the problem Andriy encountered:
>>>>>> I can confirm - this fixed the issue for me.
>>>>>> David, thanks!
>>>>> Does libc_r still work with patch applied ?
>>>> In what sense?
>>>> The test program that I posted seems to hang in both cases (patched and 
>>>> unpatched rtld).
>>> The David' patch changes the code used to support libc_r operations.
>>> Even on CURRENT, if you run 4.x-compiled binary with the support of
>>> compat-4x libraries, this code from /libexec/ld-elf.so.1 (installed
>>> by CURRENT buildworld) provides locking for rtld.
>> I understand, but I am not sure what exactly needs to be tested.
>> "Still works" is too broad in this context.
> 
> I am not sure too. As I said, this one of the reason I prefered to not
> touch that code.

It should not affect other code outside the rtld. In fact, this patch
fixes the maintenance of synchronization between locks and thread_flag.
In current code, if you acquire a rwlock, and then acquire second
rwlock, the first one will work, but acquiring second lock will fail
and thread_flag is out of sync, this results bit flag leaking in
thread_flag, and later a _rtld_thread_init() call will transfer the
unlocked rwlock state to libthr as locked state, also the existing
code does not distinguish reader lock and writer lock, it blindly 
transfer lock state as write-lock, fortunately, in correct case,
it should not be called with any lock held, so the transferring
does not occur.
Another question is why should dl_iterate_phdr() use exclusive lock ?
doesn't this cause all C++ exception to be executed in serialization
manner ?

Regards,
David Xu



More information about the freebsd-threads mailing list