puzzled: fork +libthr
eischen at vigrid.com
Sun Apr 17 15:42:07 UTC 2011
On Sun, 17 Apr 2011, Andriy Gapon wrote:
> on 16/04/2011 14:46 Andriy Gapon said the following:
>> The second puzzle is the EPERM return value itself, on stable/8.
>> From what I seem chromium does a bunch of forks before it gets to the place of
>> interest. My debugging shows that those forks are "single-threaded" (i.e. code
>> in thr_fork.c is not called). And then in a process/thread that makes that
>> pthread_cond_wait call I see that libthr and kernel have different opinions
>> about what current TID is. Userland part uses what is actually a kernel TID of
>> its parent thread (the one that called fork). And given how the work is divided
>> between userland and kernel in libthr, that mismatch leads to serious consequences.
>> So my question is why libthr doesn't see its actual TID. Maybe some
>> initialization code is not invoked. BTW, chromium is linked to both libc and
>> libthr (per ldd). But it seems that there are no pthread calls up the fork
>> chain until that pthread_cond_wait call.
> The second problem seems to be caused by chrome binary being linked to libc and
> libthr in "incorrect order", libc comes before libthr in ldd output. My
> debugging shows that fork is resolved from libc, not from libthr.
> Not sure what to blame here:
> - build toolchain for putting libc before libthr
> - rtld for not preferring libthr over libc
> - libc/libthr for being split into two pieces in the current way
- The build procedure for chromium.
libc/[libc_r, libpthread, libthr] have always behaved that
way since the libc/libc_r split.
More information about the freebsd-threads