Segfault when mapping libpthread -> libthr
Joe Peterson
lavajoe at gentoo.org
Fri Sep 14 16:22:43 PDT 2007
Ivan Voras wrote:
> Joe Peterson wrote:
>
>> So the question now (which I am currently investigting) is how could
>> this happen? I have used ldd to examine the binaries and all libs, and
>> they all show libpthread mapped to libthr. I do not know of a way for
>> libmap.conf to be bypassed (someone suggested a hard-coded lib
>> file/path). If anyone has ideas, please let me know. Otherwise I'll
>> keep plugging away at this and report the results when I figure it out.
>
> Hmmm, maybe static linkage of libpthread? But why would anyone do such a
> thing?
Yeah, that would be strange. But when I move libpthread.so out of the
way, the crash stops happening, so I assume it's dynamically referencing
it. Strangely, it doesn't complain when I move it, so it's as if
something is grabbing libpthread.so if it's there but falling back to
something else (I assume libthr.so) if not. Here's the output of ldd
/usr/bin/mogrify:
/usr/bin/mogrify:
libMagick.so.10 => /usr/lib/libMagick.so.10 (0x28086000)
libWand.so.10 => /usr/lib/libWand.so.10 (0x2826c000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x2832b000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2837f000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2839e000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x283c9000)
libpthread.so.2 => /usr/lib/libthr.so.2 (0x284eb000)
libiconv.so.2 => /lib/libiconv.so.2 (0x284fd000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x285db000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x285e9000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x28638000)
libz.so.1 => /lib/libz.so.1 (0x286b3000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x286c5000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x286ce000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x286e5000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x287d0000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x287d3000)
librpcsvc.so.3 => /usr/lib/librpcsvc.so.3 (0x287d8000)
libm.so.4 => /lib/libm.so.4 (0x287e0000)
libc.so.6 => /lib/libc.so.6 (0x287f6000)
libgcc_s.so.1 =>
/usr/lib/gcc/i686-gentoo-freebsd6.2/4.2.0/libgcc_s.so.1 (0x288e0000)
Note that the only reference to threads is the redirection from
libmap.conf of libpthread -> libthr... So I cannot see how anything
would pick up the real libpthread.
-Joe
More information about the freebsd-threads
mailing list