puzzled: fork +libthr
avg at FreeBSD.org
Sat Apr 16 11:46:35 UTC 2011
I am trying to debug this chromium issue:
Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the
problem that interests me is that pthread_cond_wait() returns EPERM where it
shouldn't. That happens on stable/8.
I compared ktrace of chromium on stable/8 and head. Startup traces are very
similar until execution gets to one particular place. At that place stable/8
chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and that's
where EPERM is returned. On the other hand it seems that head chromium executes
something different at exactly the same place, perhaps sem_wait - I see
_umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why chromimum
build or run-time chooses a different thing to call/use at that place.
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.
Maybe this could ring a bell for someone knowledgeable in the area.
More information about the freebsd-hackers