on 17/04/2011 18:21 Daniel Eischen said the following: > 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.
Well, I wouldn't blame it so expressly: -pthread is the first option on the linkage command line, there is -lc there also. I would expect that that would do the right thing, but it doesn't. And that's a PITA for porting. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
