From owner-freebsd-threads@FreeBSD.ORG Fri Sep 26 16:43:12 2014 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BFB099A for ; Fri, 26 Sep 2014 16:43:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1207646 for ; Fri, 26 Sep 2014 16:43:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8QGh6LR047149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2014 19:43:06 +0300 (EEST) (envelope-from kostik@tom.home) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8QGh6LR047149 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8QGh611047148; Fri, 26 Sep 2014 19:43:06 +0300 (EEST) (envelope-from kostik) Date: Fri, 26 Sep 2014 19:43:06 +0300 From: Konstantin Belousov To: Guillaume Friloux Subject: Re: Segfault from libthr.so. Message-ID: <20140926164306.GE8870@kib.kiev.ua> References: <20140926150001.GF7885@Jetdail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140926150001.GF7885@Jetdail> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:43:12 -0000 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@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > root@sds:/tmp # gcc48 main.c -o main > root@sds:/tmp # ./main > Hello World! > root@sds:/tmp # gcc48 main.c -o main -lpthread > root@sds:/tmp # ./main > Hello World! > root@sds:/tmp # gcc48 main.c -o main -lssp > root@sds:/tmp # ./main > Hello World! > root@sds:/tmp # gcc48 main.c -o main -lssp -lpthread > root@sds:/tmp # ./main > Hello World! > root@sds:/tmp # gcc48 main.c -o main -lpthread -lssp > root@sds:/tmp # ./main > Segmentation fault (core dumped) > root@sds:/tmp # > > Here is what gdb says : > root@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 > > 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 ?