Bugzilla Bug 192711

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 an attachment (id=131069) [edit]
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 an attachment (id=131821) [edit]
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 an attachment (id=131840) [edit]
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 an attachment (id=131841) [edit]
Move libthr to /

Created an attachment (id=131864) [edit]
freebsd-lib-6.2-r3.euild

Created an attachment (id=131934) [edit]
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 an attachment (id=132001) [edit]
freebsd-lib-6.2-r2.ebuild

Roy, what do you think of this patch?

In portage now, hope we haven't broken too much!