In future versions of FreeBSD, the new threading lib (libthr) will replace libpthreads and libc_r. In 6.2, we now use libmap.conf to map these older libs to libthr, but this does not always prevent symbols from the older libs from sneaking into executables, either dynamically or statically. If the symbols become mixed, on the i386 arch (in this case), the %%gs register can get stomped on by different libraries and wreak havoc, sometimes resulting in a crash. If no crash results, even more bizarre instability could potentially occur. I first found this running ImageMagick's mogrify utility. Many mutex locks and unlocks happen, and at some point the "curthread" value (stored in %%gs) changes to point to an unitialized thread, and a crash results. Not all of us could initially get the crash to happen (could have been memory layout?). Note that compiling ImageMagick with "--without-threads" still reveals the issue; the linker seems to still want to pull in pthreads. Removing /usr/lib/libpthread.so *after* mogrify was compiled fixed the issue, since the older symbols could not then be used. However, compiling Imagemagick without libpthread.so in place then resulted in /usr/lib/libpthread.a being linked statically, and the problem continued. One solution is to replace the actual libpthread files (.a and .so) with links to the libthr files. Since libmap.conf now also maps libc_r to libthr, we should probably also do the same and link these to libthr. I am testing this now.
Created attachment 131069 [details, diff] freebsd-lib-6.2-r3.ebuild This ebuild patch will re-link the libs as described; I am testing this setup now.
I have been testing two g/fbsd systems with this patch installed. One uses GCC 4.1.2, and the other 4.2.0, and both now use Xorg 1.4 (one upgraded while patch installed). Both systems also have had 'emerge system' performed. Both have worked flawlessly, so I recommend incorporating this patch into freebsd-lib until the specific cause of the symbol mixing is determined. When the symbols are confused, we know segfaults can result, but I suspect even worse insidious issues could result from the corruption of the %%gs register contents.
Created attachment 131821 [details, diff] freebsd-lib-6.2-r3.ebuild New version of the ebuild that does not build libpthread or libc_r (done with make options). It then does not need to remove these libs before making the symlinks.
Created attachment 131840 [details, diff] freebsd-lib-6.2-r3.ebuild I think is is better so that bins built against libpthread.so.2 still work. Also, we need to move libthr to / now.
Created attachment 131841 [details, diff] Move libthr to /
Created attachment 131864 [details, diff] freebsd-lib-6.2-r3.euild
Created attachment 131934 [details, diff] freebsd-lib Preserve old libs is probably better.
Hmm, only thing I don't like about preserving the libs is that some people will have them and some won't. For example, they are gone now on my sys, so I will not get them back by re-installing freebsd-lib... So freebsd-lib is not then as consistent machine to machine. Also, the latest patch doesn't build libc_r, but it also does not link it to libthr. Did you intend to get rid of it completely? That might be OK (it's not in 7.0-CURRENT at all anyway)...
Created attachment 132001 [details, diff] freebsd-lib-6.2-r2.ebuild Roy, what do you think of this patch?
In portage now, hope we haven't broken too much!
