Segfault from libthr.so.

Konstantin Belousov kostikbel at gmail.com
Fri Sep 26 16:43:12 UTC 2014


On Fri, Sep 26, 2014 at 05:00:02PM +0200, Guillaume Friloux wrote:
> Hello,
> 
> First of all, i am new to the BSD world.
> 
> I am here to report a problem when linking an hello world with -lssp and -lpthread.
> I am running :
> FreeBSD sds 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root at snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> root at sds:/tmp #    gcc48 main.c -o main 
> root at sds:/tmp #    ./main 
> Hello World!
> root at sds:/tmp #    gcc48 main.c -o main -lpthread
> root at sds:/tmp #    ./main
> Hello World!
> root at sds:/tmp #    gcc48 main.c -o main -lssp
> root at sds:/tmp #    ./main
> Hello World!
> root at sds:/tmp #    gcc48 main.c -o main -lssp -lpthread
> root at sds:/tmp #    ./main
> Hello World!
> root at sds:/tmp #    gcc48 main.c -o main -lpthread -lssp 
> root at sds:/tmp #    ./main
> Segmentation fault (core dumped)
> root at sds:/tmp #    
> 
> Here is what gdb says :
> root at sds:/tmp #   gdb main main.core 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
> Core was generated by `main'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
> Loaded symbols for /lib/libthr.so.3
> Reading symbols from /lib/libssp.so.0...(no debugging symbols found)...done.
> Loaded symbols for /lib/libssp.so.0
> Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x000000080082e604 in pthread_testcancel () from /lib/libthr.so.3
> [New LWP 100071]
> (gdb) bt
> #0  0x000000080082e604 in pthread_testcancel () from /lib/libthr.so.3
> #1  0x0000000800826706 in open () from /lib/libthr.so.3
> #2  0x0000000800a41227 in __gets_chk () from /lib/libssp.so.0
> #3  0x0000000800a413d2 in __chk_fail () from /lib/libssp.so.0
> #4  0x0000000800a40ace in .init () from /lib/libssp.so.0
> #5  0x00007fffffffd120 in ?? ()
> #6  0x0000000800604691 in r_debug_state () from /libexec/ld-elf.so.1
> #7  0x0000000800603d27 in __tls_get_addr () from /libexec/ld-elf.so.1
> #8  0x0000000800602089 in .text () from /libexec/ld-elf.so.1
> #9  0x0000000000000000 in ?? ()
> 
> Here is the hello world code :
> #include <stdio.h>
> 
> int main(int argc, char **argv)
> {
>    printf("Hello World!\n");
>    return 0;
> }
> 
> 
> Thanks for taking time to read this.


So, what is the problem, from your PoV ?
Linking libssp after libthr causes libssp constructors run before
libthr initialization, which causes the behaviour you see. The libssp
uses something which is interposed by libthr, but still not ready at
the libssp init time. Your example of linking with different order
demostrates you the right way to treat libthr.

So again, what is the problem ?


More information about the freebsd-threads mailing list