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.
--
DE
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
