From owner-freebsd-threads@FreeBSD.ORG Mon Aug 25 11:06:59 2008 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D45A1065671 for ; Mon, 25 Aug 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3A58FC15 for ; Mon, 25 Aug 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PB6xxI027920 for ; Mon, 25 Aug 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PB6wJI027916 for freebsd-threads@FreeBSD.org; Mon, 25 Aug 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Aug 2008 11:06:58 GMT Message-Id: <200808251106.m7PB6wJI027916@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 11:06:59 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread(3) dont dequeue signals s threa/34536 threads accept() blocks other threads s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/118715 threads kse problem o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 23 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/122923 threads 'nice' does not prevent background process from steali o kern/126128 threads [patch] pthread_condattr_getpshared is broken 12 problems total. From owner-freebsd-threads@FreeBSD.ORG Thu Aug 28 20:52:50 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC69D106569B for ; Thu, 28 Aug 2008 20:52:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 23ED98FC1C for ; Thu, 28 Aug 2008 20:52:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KYoU4-0004Ua-1c; Thu, 28 Aug 2008 23:52:48 +0300 Message-ID: <48B7101E.7060203@icyb.net.ua> Date: Thu, 28 Aug 2008 23:52:46 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <48B70A98.5060501@icyb.net.ua> In-Reply-To: <48B70A98.5060501@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 20:52:50 -0000 on 28/08/2008 23:29 Andriy Gapon said the following: > I tracked all calls to functions of _thr_rtld_*lock* family and it seems > that the lock in question gets acquired for writing before the above > access. The stack: > #0 _thr_rtld_wlock_acquire (lock=0x8387740) at > /system/src/lib/libthr/thread/thr_rtld.c:144 > #1 0x282a6dcc in _rtld_thread_init () from /libexec/ld-elf.so.1 > #2 0x28f91af6 in _thr_rtld_init () at > /system/src/lib/libthr/thread/thr_rtld.c:238 > #3 0x28f938db in _thr_setthreaded (threaded=1) at > /system/src/lib/libthr/thread/thr_kern.c:56 > #4 0x28f8d208 in _pthread_create (thread=0x831cb90, attr=0x0, > start_routine=0x8170ce0 , arg=0x831cb8c) > at /system/src/lib/libthr/thread/thr_create.c:64 > #5 0x08170bd8 in Thread::start (this=0x831cb8c) at client/Thread.cpp:41 > #6 0x080abfb4 in HashManager::startup (this=0x831cb60) at HashManager.h:97 > #7 0x0809f4d6 in startup (f=0x827a2c0 const&)>, p=0x0) at client/DCPlusPlus.cpp:82 > #8 0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61 Quick followup: I rebuilt ld-elf.so with debug symbols and it seems that at the following place in rtld_lock.c 'flags' variable gets assigned a value of five (5): (gdb) fr 2 #2 0x282a86bf in _rtld_thread_init (pli=0xbfbfe66c) at /system/src/libexec/rtld-elf/rtld_lock.c:275 275 flags = thread_mask_set(~0); (gdb) list 270 { 271 int flags, i; 272 void *locks[RTLD_LOCK_CNT]; 273 274 /* disable all locking while this function is running */ 275 flags = thread_mask_set(~0); 276 277 if (pli == NULL) 278 pli = &deflockinfo; 279 ... (gdb) p flags $10 = 5 Wait, I think I just found something: (gdb) b rtld_lock.c:143 if mask != 1 Breakpoint 8 at 0x282a8311: file /system/src/libexec/rtld-elf/rtld_lock.c, line 143. (gdb) c ... (gdb) bt #0 def_thread_set_flag (mask=4) at /system/src/libexec/rtld-elf/rtld_lock.c:143 #1 0x282a83e0 in thread_mask_set (mask=4) at /system/src/libexec/rtld-elf/rtld_lock.c:165 #2 0x282a8410 in wlock_acquire (lock=0x282cddb4) at /system/src/libexec/rtld-elf/rtld_lock.c:198 #3 0x282a58b2 in dl_iterate_phdr (callback=0x28f84fc0 <__fixunssfdi+4352>, param=0xbfbfe200) at /system/src/libexec/rtld-elf/rtld.c:2103 #4 0x28f8586f in _Unwind_Find_FDE () from /lib/libgcc_s.so.1 #5 0x28f8267c in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 #6 0x28f833be in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 #7 0x28f838c0 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #8 0x28ee045d in __cxa_throw () from /usr/lib/libstdc++.so.6 #9 0x080d60e2 in File (this=0xbfbfe710, aFileName=@0xbfbfe71c, access=1, mode=1) at client/File.cpp:227 #10 0x08192d6f in Util::initialize () at client/Util.cpp:102 #11 0x0809f3cc in startup (f=0x827a2c0 , p=0x0) at client/DCPlusPlus.cpp:51 #12 0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61 So can all this be a result of an exception thrown before threads are initialized? Is this something that might already be fixed in HEAD/trunk or in RELENG_7? (I seem to vaguely remember something related). -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Thu Aug 28 21:14:20 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64722106567B for ; Thu, 28 Aug 2008 21:14:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4F78FC12 for ; Thu, 28 Aug 2008 21:14:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KYo7M-00044R-6c; Thu, 28 Aug 2008 23:29:20 +0300 Message-ID: <48B70A98.5060501@icyb.net.ua> Date: Thu, 28 Aug 2008 23:29:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 21:14:20 -0000 I've got quite a strange issue with only one particular threaded program. My system is 7-STABLE from around July 6 (rather old, I know). I, of course, use libthr as a thread library. I have plenty of threaded programs and all of them except one are working perfectly (firefox, thunderbird, KDE). The bad one is linuxdcpp (net-p2p/linuxdcpp, linuxdcpp-1.0.2). I built it with debug enabled and also rebuilt libthr with debug. It seems that the program hangs in the very first call to pthread_create. Here's a stack trace of the hanging program: #0 _thr_umtx_wait (mtx=0x838774c, id=0, timeout=0x0) at /system/src/lib/libthr/thread/thr_umtx.c:93 #1 0x28f9168c in _thr_rtld_rlock_acquire (lock=0x8387740) at /system/src/lib/libthr/thread/thr_rtld.c:129 #2 0x282a6a27 in dlopen () from /libexec/ld-elf.so.1 #3 0x282a491d in dladdr () from /libexec/ld-elf.so.1 #4 0x282a1469 in ?? () from /libexec/ld-elf.so.1 #5 0x289b3600 in ?? () #6 0x000000d8 in ?? () #7 0x000186d1 in ?? () #8 0x00000000 in ?? () #9 0x08303a00 in ?? () #10 0x00000246 in ?? () #11 0x289b3600 in ?? () #12 0x000000d8 in ?? () #13 0x28f94b5f in _tcb_ctor (thread=0x8303a00, initial=0) at /system/src/lib/libthr/arch/i386/i386/pthread_md.c:46 #14 0x28f94215 in _thr_alloc (curthread=0x8302100) at /system/src/lib/libthr/thread/thr_list.c:169 #15 0x28f8d22e in _pthread_create (thread=0x831cb90, attr=0x0, start_routine=0x8170ce0 , arg=0x831cb8c) at /system/src/lib/libthr/thread/thr_create.c:68 #16 0x08170bd8 in Thread::start (this=0x831cb8c) at client/Thread.cpp:41 #17 0x080abfb4 in HashManager::startup (this=0x831cb60) at HashManager.h:97 #18 0x0809f4d6 in startup (f=0x827a2c0 , p=0x0) at client/DCPlusPlus.cpp:82 #19 0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61 I tracked all calls to functions of _thr_rtld_*lock* family and it seems that the lock in question gets acquired for writing before the above access. The stack: #0 _thr_rtld_wlock_acquire (lock=0x8387740) at /system/src/lib/libthr/thread/thr_rtld.c:144 #1 0x282a6dcc in _rtld_thread_init () from /libexec/ld-elf.so.1 #2 0x28f91af6 in _thr_rtld_init () at /system/src/lib/libthr/thread/thr_rtld.c:238 #3 0x28f938db in _thr_setthreaded (threaded=1) at /system/src/lib/libthr/thread/thr_kern.c:56 #4 0x28f8d208 in _pthread_create (thread=0x831cb90, attr=0x0, start_routine=0x8170ce0 , arg=0x831cb8c) at /system/src/lib/libthr/thread/thr_create.c:64 #5 0x08170bd8 in Thread::start (this=0x831cb8c) at client/Thread.cpp:41 #6 0x080abfb4 in HashManager::startup (this=0x831cb60) at HashManager.h:97 #7 0x0809f4d6 in startup (f=0x827a2c0 , p=0x0) at client/DCPlusPlus.cpp:82 #8 0x0827a571 in main (argc=1, argv=0xbfbfe844) at linux/wulfor.cc:61 It seems that for all other programs there is no such call as the above ( I mean wlock_acquire). I didn't have debug symbols in rtld when I executed this test, unfortunately. The problem is 100% reproducible, so I can get any additional debugging info. I wonder what can be so special about this program, what can be going wrong. I didn't quite get the logic with flags and masks in _rtld_thread_init (especially when lockinfo is still default, but the issue seems to be related to that. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Thu Aug 28 21:42:02 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558481065694 for ; Thu, 28 Aug 2008 21:42:02 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6658FC13 for ; Thu, 28 Aug 2008 21:42:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KYpFg-0006Go-Ma; Fri, 29 Aug 2008 00:42:00 +0300 Message-ID: <48B71BA6.5040504@icyb.net.ua> Date: Fri, 29 Aug 2008 00:41:58 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> In-Reply-To: <48B7101E.7060203@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 21:42:02 -0000 on 28/08/2008 23:52 Andriy Gapon said the following: > So can all this be a result of an exception thrown before threads are > initialized? This seems to be it. I can reproduce the issue with the following small C++ program: /*********************************************/ #include static void * thrfunc(void * arg) { return NULL; } int main(void) { pthread_t thr; try { throw int(1); } catch (...) {} pthread_create(&thr, NULL, thrfunc, NULL); return 0; } /*********************************************/ $ uname -a ... FreeBSD 7.0-STABLE #9: Sun Jul 6 17:13:22 EEST 2008 ... i386 -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 13:41:59 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95CF41065682 for ; Fri, 29 Aug 2008 13:41:59 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0238FC0A for ; Fri, 29 Aug 2008 13:41:59 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m7TDTZW8024502 for ; Fri, 29 Aug 2008 07:29:35 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m7TD4sNm027101; Fri, 29 Aug 2008 07:04:54 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m7TD4r6W027098; Fri, 29 Aug 2008 07:04:53 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18615.62453.623443.27126@gromit.timing.com> Date: Fri, 29 Aug 2008 07:04:53 -0600 From: John Hein To: Andriy Gapon In-Reply-To: <48B71BA6.5040504@icyb.net.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 13:41:59 -0000 Andriy Gapon wrote at 00:41 +0300 on Aug 29, 2008: > This seems to be it. > I can reproduce the issue with the following small C++ program: > > /*********************************************/ > #include > > > static void * thrfunc(void * arg) > { > return NULL; > } > > int main(void) > { > pthread_t thr; > > try { > throw int(1); > } > catch (...) {} > > pthread_create(&thr, NULL, thrfunc, NULL); > > return 0; > } > /*********************************************/ > > > $ uname -a > ... FreeBSD 7.0-STABLE #9: Sun Jul 6 17:13:22 EEST 2008 ... i386 FYI... I reproduced it on an older 7-stable (May 07), too (stuck in uwait). But it works fine on 6-stable with libthr or libpthread. From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 14:34:10 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778F6106567E for ; Fri, 29 Aug 2008 14:34:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1553E8FC1A for ; Fri, 29 Aug 2008 14:34:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZ4gb-000K00-Ty; Fri, 29 Aug 2008 17:10:50 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TEAhnx007840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 17:10:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TEAhxb057105; Fri, 29 Aug 2008 17:10:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7TEAhv1057100; Fri, 29 Aug 2008 17:10:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Aug 2008 17:10:43 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20080829141043.GX2038@deviant.kiev.zoral.com.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YvxfeT9y/1FRS2+9" Content-Disposition: inline In-Reply-To: <48B71BA6.5040504@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZ4gb-000K00-Ty bdab99369f9b855193e40e9a23b484f5 X-Terabit: YES Cc: davidxu@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 14:34:10 -0000 --YvxfeT9y/1FRS2+9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2008 at 12:41:58AM +0300, Andriy Gapon wrote: > on 28/08/2008 23:52 Andriy Gapon said the following: > >So can all this be a result of an exception thrown before threads are=20 > >initialized? >=20 > This seems to be it. > I can reproduce the issue with the following small C++ program: >=20 > /*********************************************/ > #include >=20 >=20 > static void * thrfunc(void * arg) > { > return NULL; > } >=20 > int main(void) > { > pthread_t thr; >=20 > try { > throw int(1); > } > catch (...) {} >=20 > pthread_create(&thr, NULL, thrfunc, NULL); >=20 > return 0; > } > /*********************************************/ >=20 >=20 > $ uname -a > ... FreeBSD 7.0-STABLE #9: Sun Jul 6 17:13:22 EEST 2008 ... i386 >=20 > --=20 > Andriy Gapon I am wondering why did you not fixed it youself with all this information. Anyway, patch below seems to work for me. David may have an opinion on the change. diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c index f96bba9..785d610 100644 --- a/lib/libthr/thread/thr_init.c +++ b/lib/libthr/thread/thr_init.c @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) if (_thread_event_mask & TD_CREATE) _thr_report_creation(curthread, curthread); } + + if (_thr_isthreaded() =3D=3D 0) + _thr_setthreaded(1); } =20 /* --YvxfeT9y/1FRS2+9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki4A2IACgkQC3+MBN1Mb4ghwACg48Cq54kIYCRiNPZv4+9fQKsJ sycAniWJY6CZ2kw79wGzxCWaJfPCvq9L =Rdug -----END PGP SIGNATURE----- --YvxfeT9y/1FRS2+9-- From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 14:36:52 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87856106567C; Fri, 29 Aug 2008 14:36:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 27E9C8FC1B; Fri, 29 Aug 2008 14:36:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZ55n-000NU8-4h; Fri, 29 Aug 2008 17:36:51 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TEajhc009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 17:36:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TEaj12022295; Fri, 29 Aug 2008 17:36:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7TEaj9u022294; Fri, 29 Aug 2008 17:36:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Aug 2008 17:36:45 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20080829143645.GY2038@deviant.kiev.zoral.com.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="krsqJi1PDCheOQxO" Content-Disposition: inline In-Reply-To: <48B8052A.6070908@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZ55n-000NU8-4h 66cf6bd2f49013fbb041cf2f64e2e3bc X-Terabit: YES Cc: davidxu@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 14:36:52 -0000 --krsqJi1PDCheOQxO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: >=20 > Kostik, thanks! >=20 > on 29/08/2008 17:10 Kostik Belousov said the following: > > I am wondering why did you not fixed it youself with all this informati= on. >=20 > I am wondering that myself now :-) > I got bogged in rtld details and simply didn't think about the solution > of doing setthreaded earlier. >=20 > I will try your patch a couple of hours later. > BTW, a forward question - should this patch help in the case of an > exception thrown (and caught) before main(), i.e. in constructors of > static/global objects? If the objects are from the executable, then yes. I do not know about present situation, but some time ago g++ and several other compilers called ctr for global objects from the main() function. Regardeless of this, init for main executable shall be called after init for dependencies is finished. See initlist_add_objects(). On the other hand, ctr calls from linked dso may get fixed in regard of exception throwing, or may not, depending on the relative order of the dso loading against libthr. >=20 > > Anyway, patch below seems to work for me. David may have an opinion on > > the change. > >=20 > > diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c > > index f96bba9..785d610 100644 > > --- a/lib/libthr/thread/thr_init.c > > +++ b/lib/libthr/thread/thr_init.c > > @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) > > if (_thread_event_mask & TD_CREATE) > > _thr_report_creation(curthread, curthread); > > } > > + > > + if (_thr_isthreaded() =3D=3D 0) > > + _thr_setthreaded(1); > > } > > =20 > > /* >=20 >=20 > --=20 > Andriy Gapon --krsqJi1PDCheOQxO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki4CXwACgkQC3+MBN1Mb4jUoACgkl9pFn0bJG9TCvbVEwPUrNll sP4An2H6Ur59mzl7qiNd+CUXegQz5VJY =yf2+ -----END PGP SIGNATURE----- --krsqJi1PDCheOQxO-- From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 14:46:16 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 974B6106566C; Fri, 29 Aug 2008 14:46:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 43A078FC18; Fri, 29 Aug 2008 14:46:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C9B87744189; Fri, 29 Aug 2008 17:18:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovAWzFYyU60e; Fri, 29 Aug 2008 17:18:20 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2EA8B744172; Fri, 29 Aug 2008 17:18:20 +0300 (EEST) Message-ID: <48B8052A.6070908@icyb.net.ua> Date: Fri, 29 Aug 2008 17:18:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Kostik Belousov References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20080829141043.GX2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: davidxu@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 14:46:16 -0000 Kostik, thanks! on 29/08/2008 17:10 Kostik Belousov said the following: > I am wondering why did you not fixed it youself with all this information. I am wondering that myself now :-) I got bogged in rtld details and simply didn't think about the solution of doing setthreaded earlier. I will try your patch a couple of hours later. BTW, a forward question - should this patch help in the case of an exception thrown (and caught) before main(), i.e. in constructors of static/global objects? > Anyway, patch below seems to work for me. David may have an opinion on > the change. > > diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c > index f96bba9..785d610 100644 > --- a/lib/libthr/thread/thr_init.c > +++ b/lib/libthr/thread/thr_init.c > @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) > if (_thread_event_mask & TD_CREATE) > _thr_report_creation(curthread, curthread); > } > + > + if (_thr_isthreaded() == 0) > + _thr_setthreaded(1); > } > > /* -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 14:50:15 2008 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD681065758 for ; Fri, 29 Aug 2008 14:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 15B548FC19 for ; Fri, 29 Aug 2008 14:50:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TEo8IJ059865 for ; Fri, 29 Aug 2008 14:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7TEo80c059864; Fri, 29 Aug 2008 14:50:08 GMT (envelope-from gnats) Resent-Date: Fri, 29 Aug 2008 14:50:08 GMT Resent-Message-Id: <200808291450.m7TEo80c059864@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Oleg Dolgov Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF2E1065672 for ; Fri, 29 Aug 2008 14:48:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id BAF038FC1D for ; Fri, 29 Aug 2008 14:48:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TEmP8m020627 for ; Fri, 29 Aug 2008 14:48:25 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m7TEmPbg020616; Fri, 29 Aug 2008 14:48:25 GMT (envelope-from nobody) Message-Id: <200808291448.m7TEmPbg020616@www.freebsd.org> Date: Fri, 29 Aug 2008 14:48:25 GMT From: Oleg Dolgov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/126950: rtld malloc is thread-unsafe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 14:50:15 -0000 >Number: 126950 >Category: threads >Synopsis: rtld malloc is thread-unsafe >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 29 14:50:08 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Oleg Dolgov >Release: 7.0-RELEASE >Organization: Sunbay >Environment: >Description: rtld internal memory allocator are not thread safe. It use global array 'nextf' of free blocks. Dynamic loader can be easily segfaulted with parallel invocations of rtld operations from multiple threads. Test case and fix for problems exposed by the test are attached. precondition: apply patch kern/95339 (fixes for dlopen mt behavior) >How-To-Repeat: Use the following test by Kazuaki Oda to see errant behaviour, but first apply patch from kern/95339. #include #include #include #include #include #include #define NTHREADS 10 void *func(void *dummy); int main(void) { pthread_t tids[NTHREADS]; int error; int i; for (i = 0; i < NTHREADS; i++) { error = pthread_create(&tids[i], NULL, func, NULL); if (error) errc(1, error, "pthread_create"); } for (;;) sleep(1); /* NOTREACHED */ exit(0); } void *func(void *dummy) { void *h; unsigned long c = 0; for (;;) { if ((h = dlopen("/usr/lib/libm.so", RTLD_NOW)) == NULL) { fprintf(stderr, "dlopen: %s\n", dlerror()); continue; } if (dlclose(h) == -1) fprintf(stderr, "dlclose: %s\n", dlerror()); if (c++ == 10000) { printf(".\n"); c = 0; } } /* NOTREACHED */ return (NULL); } >Fix: We need synchronization, but cant use rtld_bind_lock or similar because memory allocation even occurred from _rtld (init_rtld) function (and lock's space also allocated with malloc), in context, where dynamic linker itself has not been relocated yet. Patch attached with submission follows: --- rtld-elf/malloc.c 2008-08-29 16:18:17.000000000 +0300 +++ /usr/src/libexec/rtld-elf/malloc.c 2008-08-29 17:42:38.000000000 +0300 @@ -58,6 +58,8 @@ #include #include #include +#include + #ifndef BSD #define MAP_COPY MAP_PRIVATE #define MAP_FILE 0 @@ -68,6 +70,10 @@ #define NEED_DEV_ZERO 1 #endif +static volatile u_int mem_mtx = 0; +static void mtx_acquire(); +static void mtx_release(); + static void morecore(); static int findbucket(); @@ -152,8 +158,8 @@ static void xprintf(const char *, ...); #define TRACE() xprintf("TRACE %s:%d\n", __FILE__, __LINE__) -void * -malloc(nbytes) +static void * +__malloc(nbytes) size_t nbytes; { register union overhead *op; @@ -299,8 +305,8 @@ } } -void -free(cp) +static void +__free(cp) void *cp; { register int size; @@ -341,8 +347,8 @@ */ int realloc_srchlen = 4; /* 4 should be plenty, -1 =>'s whole list */ -void * -realloc(cp, nbytes) +static void * +__realloc(cp, nbytes) void *cp; size_t nbytes; { @@ -516,3 +522,49 @@ (void)write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } + +/* + * Thread safe allocator + */ + +static void mtx_acquire() +{ + for ( ; ; ) { + if (atomic_cmpset_acq_int(&mem_mtx, 0, 1)) + break; + } +} + +static void mtx_release() +{ + atomic_add_rel_int(&mem_mtx, -1); +} + +void * +malloc(size_t nbytes) +{ + void *p; + mtx_acquire(); + p = __malloc(nbytes); + mtx_release(); + return p; +} + +void * +realloc(void *cp, size_t nbytes) +{ + void *p; + mtx_acquire(); + p = __realloc(cp, nbytes); + mtx_release(); + return p; +} + +void +free(void *cp) +{ + mtx_acquire(); + __free(cp); + mtx_release(); +} + >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 16:47:06 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37CEB1065679; Fri, 29 Aug 2008 16:47:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 554D68FC08; Fri, 29 Aug 2008 16:47:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m7TGP9er009267; Fri, 29 Aug 2008 12:25:09 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 29 Aug 2008 12:25:09 -0400 (EDT) Date: Fri, 29 Aug 2008 12:25:09 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kostik Belousov In-Reply-To: <20080829143645.GY2038@deviant.kiev.zoral.com.ua> Message-ID: References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org, Andriy Gapon , davidxu@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 16:47:06 -0000 On Fri, 29 Aug 2008, Kostik Belousov wrote: > On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: >> >> Kostik, thanks! >> >> on 29/08/2008 17:10 Kostik Belousov said the following: >>> I am wondering why did you not fixed it youself with all this information. >> >> I am wondering that myself now :-) >> I got bogged in rtld details and simply didn't think about the solution >> of doing setthreaded earlier. >> >> I will try your patch a couple of hours later. >> BTW, a forward question - should this patch help in the case of an >> exception thrown (and caught) before main(), i.e. in constructors of >> static/global objects? > If the objects are from the executable, then yes. I do not know about > present situation, but some time ago g++ and several other compilers > called ctr for global objects from the main() function. Regardeless > of this, init for main executable shall be called after init for > dependencies is finished. See initlist_add_objects(). > > On the other hand, ctr calls from linked dso may get fixed in regard > of exception throwing, or may not, depending on the relative order of > the dso loading against libthr. > >> >>> Anyway, patch below seems to work for me. David may have an opinion on >>> the change. >>> >>> diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c >>> index f96bba9..785d610 100644 >>> --- a/lib/libthr/thread/thr_init.c >>> +++ b/lib/libthr/thread/thr_init.c >>> @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) >>> if (_thread_event_mask & TD_CREATE) >>> _thr_report_creation(curthread, curthread); >>> } >>> + >>> + if (_thr_isthreaded() == 0) >>> + _thr_setthreaded(1); >>> } >>> >>> /* I think the intent of __isthreaded (and _thr_setthreaded()) was to be set if there were more than 1 thread, not to indicate that the thread library has been initialized. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 18:40:03 2008 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF901065682 for ; Fri, 29 Aug 2008 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF9E8FC13 for ; Fri, 29 Aug 2008 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TIe36m002359 for ; Fri, 29 Aug 2008 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7TIe3in002358; Fri, 29 Aug 2008 18:40:03 GMT (envelope-from gnats) Date: Fri, 29 Aug 2008 18:40:03 GMT Message-Id: <200808291840.m7TIe3in002358@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Alexander Kabaev Cc: Subject: Re: threads/126950: rtld malloc is thread-unsafe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Kabaev List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 18:40:03 -0000 The following reply was made to PR threads/126950; it has been noted by GNATS. From: Alexander Kabaev To: Oleg Dolgov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/126950: rtld malloc is thread-unsafe Date: Fri, 29 Aug 2008 14:05:27 -0400 --Sig_/8E=R.f2Foc5pJTzysvE4Zu4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 1. The locking implementation in this patch is broken. 2. rtld malloc is not supposed to be called from multiple threads and needs to be protected by exclusive bind lock. If there are code sections that call malloc without exclusive lock held, rtld should be fixed to move them under lock protection. --=20 Alexander Kabaev --Sig_/8E=R.f2Foc5pJTzysvE4Zu4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFIuDpnQ6z1jMm+XZYRAt3lAJ47sMx7yg5cbYu+6lgwiYBuqBFVxQCgtiab ygqiHe8ciE/t+8IzQTvc4bI= =U3O0 -----END PGP SIGNATURE----- --Sig_/8E=R.f2Foc5pJTzysvE4Zu4-- From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 19:05:11 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7199B106568C; Fri, 29 Aug 2008 19:05:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8B68FC1A; Fri, 29 Aug 2008 19:05:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZ9HR-000Er9-Vu; Fri, 29 Aug 2008 22:05:10 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TJ56Rv020626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 22:05:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7TJ56Hr063959; Fri, 29 Aug 2008 22:05:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7TJ56mj063958; Fri, 29 Aug 2008 22:05:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Aug 2008 22:05:06 +0300 From: Kostik Belousov To: Daniel Eischen Message-ID: <20080829190506.GA2038@deviant.kiev.zoral.com.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8BV0TfTmv8nl9Pc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZ9HR-000Er9-Vu 355ec3db619bae4e8df7d746a1a4b460 X-Terabit: YES Cc: freebsd-threads@freebsd.org, Andriy Gapon , davidxu@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 19:05:11 -0000 --n8BV0TfTmv8nl9Pc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2008 at 12:25:09PM -0400, Daniel Eischen wrote: > On Fri, 29 Aug 2008, Kostik Belousov wrote: >=20 > >On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: > >> > >>Kostik, thanks! > >> > >>on 29/08/2008 17:10 Kostik Belousov said the following: > >>>I am wondering why did you not fixed it youself with all this=20 > >>>information. > >> > >>I am wondering that myself now :-) > >>I got bogged in rtld details and simply didn't think about the solution > >>of doing setthreaded earlier. > >> > >>I will try your patch a couple of hours later. > >>BTW, a forward question - should this patch help in the case of an > >>exception thrown (and caught) before main(), i.e. in constructors of > >>static/global objects? > >If the objects are from the executable, then yes. I do not know about > >present situation, but some time ago g++ and several other compilers > >called ctr for global objects from the main() function. Regardeless > >of this, init for main executable shall be called after init for > >dependencies is finished. See initlist_add_objects(). > > > >On the other hand, ctr calls from linked dso may get fixed in regard > >of exception throwing, or may not, depending on the relative order of > >the dso loading against libthr. > > > >> > >>>Anyway, patch below seems to work for me. David may have an opinion on > >>>the change. > >>> > >>>diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init= .c > >>>index f96bba9..785d610 100644 > >>>--- a/lib/libthr/thread/thr_init.c > >>>+++ b/lib/libthr/thread/thr_init.c > >>>@@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) > >>> if (_thread_event_mask & TD_CREATE) > >>> _thr_report_creation(curthread, curthread); > >>> } > >>>+ > >>>+ if (_thr_isthreaded() =3D=3D 0) > >>>+ _thr_setthreaded(1); > >>> } > >>> > >>> /* >=20 > I think the intent of __isthreaded (and _thr_setthreaded()) was > to be set if there were more than 1 thread, not to indicate that > the thread library has been initialized. As demonstrated by Andriy' example, we need _thr_rtld_init() be called before any rtld locks are given chance to be acquired. _thr_rtld_init() shall be protected from repeated invocation, and _thr_setthreaded() implements exactly this. If calling _thr_setthreaded(1) has not quite right intent, could you, please, suggest satisfying solution ? --n8BV0TfTmv8nl9Pc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki4SGEACgkQC3+MBN1Mb4ju8gCgt9V5U0U1C6+M+AaTpZ7aTfKY bCQAnjRDEkb2/og7uz4/mfe1vZlBrC36 =xmNy -----END PGP SIGNATURE----- --n8BV0TfTmv8nl9Pc-- From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 22:10:05 2008 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7B9106567F for ; Fri, 29 Aug 2008 22:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC5C8FC19 for ; Fri, 29 Aug 2008 22:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TMA5jL019710 for ; Fri, 29 Aug 2008 22:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7TMA53f019709; Fri, 29 Aug 2008 22:10:05 GMT (envelope-from gnats) Date: Fri, 29 Aug 2008 22:10:05 GMT Message-Id: <200808292210.m7TMA53f019709@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: "Kip Macy" Cc: Subject: Re: threads/126950: rtld malloc is thread-unsafe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kip Macy List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 22:10:05 -0000 The following reply was made to PR threads/126950; it has been noted by GNATS. From: "Kip Macy" To: "Oleg Dolgov" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: threads/126950: rtld malloc is thread-unsafe Date: Fri, 29 Aug 2008 14:41:59 -0700 I think the real solution is to serialize calls to dlopen. Please consider submitting a patch for that. -Kip On Fri, Aug 29, 2008 at 7:48 AM, Oleg Dolgov wrote: > >>Number: 126950 >>Category: threads >>Synopsis: rtld malloc is thread-unsafe >>Confidential: no >>Severity: serious >>Priority: medium >>Responsible: freebsd-threads >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: sw-bug >>Submitter-Id: current-users >>Arrival-Date: Fri Aug 29 14:50:08 UTC 2008 >>Closed-Date: >>Last-Modified: >>Originator: Oleg Dolgov >>Release: 7.0-RELEASE >>Organization: > Sunbay >>Environment: >>Description: > rtld internal memory allocator are not thread safe. It use global array 'nextf' of free blocks. Dynamic loader can be easily segfaulted with parallel invocations of rtld operations from multiple threads. Test case and fix for problems exposed by the test are attached. > > precondition: apply patch kern/95339 (fixes for dlopen mt behavior) > >>How-To-Repeat: > Use the following test by Kazuaki Oda > to see errant behaviour, but first apply patch from kern/95339. > > #include > #include > #include > #include > #include > #include > > #define NTHREADS 10 > > void *func(void *dummy); > > int main(void) > { > pthread_t tids[NTHREADS]; > int error; > int i; > > for (i = 0; i < NTHREADS; i++) { > error = pthread_create(&tids[i], NULL, func, NULL); > if (error) > errc(1, error, "pthread_create"); > } > > for (;;) > sleep(1); > > /* NOTREACHED */ > > exit(0); > } > > void *func(void *dummy) > { > void *h; > unsigned long c = 0; > > for (;;) { > if ((h = dlopen("/usr/lib/libm.so", RTLD_NOW)) == NULL) { > fprintf(stderr, "dlopen: %s\n", dlerror()); > continue; > } > if (dlclose(h) == -1) > fprintf(stderr, "dlclose: %s\n", dlerror()); > if (c++ == 10000) { > printf(".\n"); > c = 0; > } > } > > /* NOTREACHED */ > > return (NULL); > } >>Fix: > We need synchronization, but cant use rtld_bind_lock or similar because memory allocation even occurred from _rtld (init_rtld) function (and lock's space also allocated with malloc), in context, where dynamic linker itself has not been relocated yet. > > > Patch attached with submission follows: > > --- rtld-elf/malloc.c 2008-08-29 16:18:17.000000000 +0300 > +++ /usr/src/libexec/rtld-elf/malloc.c 2008-08-29 17:42:38.000000000 +0300 > @@ -58,6 +58,8 @@ > #include > #include > #include > +#include > + > #ifndef BSD > #define MAP_COPY MAP_PRIVATE > #define MAP_FILE 0 > @@ -68,6 +70,10 @@ > #define NEED_DEV_ZERO 1 > #endif > > +static volatile u_int mem_mtx = 0; > +static void mtx_acquire(); > +static void mtx_release(); > + > static void morecore(); > static int findbucket(); > > @@ -152,8 +158,8 @@ > static void xprintf(const char *, ...); > #define TRACE() xprintf("TRACE %s:%d\n", __FILE__, __LINE__) > > -void * > -malloc(nbytes) > +static void * > +__malloc(nbytes) > size_t nbytes; > { > register union overhead *op; > @@ -299,8 +305,8 @@ > } > } > > -void > -free(cp) > +static void > +__free(cp) > void *cp; > { > register int size; > @@ -341,8 +347,8 @@ > */ > int realloc_srchlen = 4; /* 4 should be plenty, -1 =>'s whole list */ > > -void * > -realloc(cp, nbytes) > +static void * > +__realloc(cp, nbytes) > void *cp; > size_t nbytes; > { > @@ -516,3 +522,49 @@ > (void)write(STDOUT_FILENO, buf, strlen(buf)); > va_end(ap); > } > + > +/* > + * Thread safe allocator > + */ > + > +static void mtx_acquire() > +{ > + for ( ; ; ) { > + if (atomic_cmpset_acq_int(&mem_mtx, 0, 1)) > + break; > + } > +} > + > +static void mtx_release() > +{ > + atomic_add_rel_int(&mem_mtx, -1); > +} > + > +void * > +malloc(size_t nbytes) > +{ > + void *p; > + mtx_acquire(); > + p = __malloc(nbytes); > + mtx_release(); > + return p; > +} > + > +void * > +realloc(void *cp, size_t nbytes) > +{ > + void *p; > + mtx_acquire(); > + p = __realloc(cp, nbytes); > + mtx_release(); > + return p; > +} > + > +void > +free(void *cp) > +{ > + mtx_acquire(); > + __free(cp); > + mtx_release(); > +} > + > > >>Release-Note: >>Audit-Trail: >>Unformatted: > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Fri Aug 29 23:30:04 2008 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D991065676 for ; Fri, 29 Aug 2008 23:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBE738FC2C for ; Fri, 29 Aug 2008 23:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TNU4wZ027174 for ; Fri, 29 Aug 2008 23:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7TNU4Yu027171; Fri, 29 Aug 2008 23:30:04 GMT (envelope-from gnats) Date: Fri, 29 Aug 2008 23:30:04 GMT Message-Id: <200808292330.m7TNU4Yu027171@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: agile@sunbay.com Cc: Subject: Re: threads/126950: rtld malloc is thread-unsafe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: agile@sunbay.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 23:30:04 -0000 The following reply was made to PR threads/126950; it has been noted by GNATS. From: agile@sunbay.com To: "Alexander Kabaev" Cc: bug-followup@FreeBSD.org Subject: Re: threads/126950: rtld malloc is thread-unsafe Date: Sat, 30 Aug 2008 02:00:10 +0300 (EEST) Thx for hint, Alexander. There only two functions, that called without bind lock: objlist_call_init, objlist_call_fini, they both use errmsg_save (which call xstrdup) errmsg_restore (which call free) Need to move them under exclusive bind lock protection. > 1. The locking implementation in this patch is broken. > 2. rtld malloc is not supposed to be called from multiple threads and > needs to be protected by exclusive bind lock. If there are code > sections that call malloc without exclusive lock held, rtld > should be fixed to move them under lock protection. > > -- > Alexander Kabaev > From owner-freebsd-threads@FreeBSD.ORG Sat Aug 30 08:30:31 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD0931065671; Sat, 30 Aug 2008 08:30:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 52DDB8FC1F; Sat, 30 Aug 2008 08:30:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZLqo-0008hG-F9; Sat, 30 Aug 2008 11:30:30 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7U8UREo063315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Aug 2008 11:30:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7U8URB0057442; Sat, 30 Aug 2008 11:30:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7U8URaB057441; Sat, 30 Aug 2008 11:30:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Aug 2008 11:30:27 +0300 From: Kostik Belousov To: Kip Macy Message-ID: <20080830083027.GD2038@deviant.kiev.zoral.com.ua> References: <200808292210.m7TMA53f019709@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cUq9BFDytUJq8bQY" Content-Disposition: inline In-Reply-To: <200808292210.m7TMA53f019709@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZLqo-0008hG-F9 f7fd9ab91494beb240798a0e23833fa5 X-Terabit: YES Cc: freebsd-threads@freebsd.org Subject: Re: threads/126950: rtld malloc is thread-unsafe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 08:30:31 -0000 --cUq9BFDytUJq8bQY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2008 at 10:10:05PM +0000, Kip Macy wrote: > The following reply was made to PR threads/126950; it has been noted by G= NATS. >=20 > From: "Kip Macy" > To: "Oleg Dolgov" > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: threads/126950: rtld malloc is thread-unsafe > Date: Fri, 29 Aug 2008 14:41:59 -0700 >=20 > I think the real solution is to serialize calls to dlopen. Please > consider submitting a patch for that. dlopen()/dlclose() need to call initializers/finalizers for dso and its dependencies. These code may recurse into the rtld, either by symbol resolution, or by calling dl*(). I tried to somewhat work around this in the patch, referenced as a prerequisite. --cUq9BFDytUJq8bQY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki5BSIACgkQC3+MBN1Mb4iiPACgz0sJ//6a5RwGE7XB2BM9E/qO Xn0AnRmf/imd6n2rQjshNrDJq0WOTUY6 =6F0o -----END PGP SIGNATURE----- --cUq9BFDytUJq8bQY-- From owner-freebsd-threads@FreeBSD.ORG Sat Aug 30 15:32:38 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 494D2106566C; Sat, 30 Aug 2008 15:32:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id BF4F28FC0C; Sat, 30 Aug 2008 15:32:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m7UFWZuX014597; Sat, 30 Aug 2008 11:32:35 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Sat, 30 Aug 2008 11:32:36 -0400 (EDT) Date: Sat, 30 Aug 2008 11:32:35 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kostik Belousov In-Reply-To: <20080829190506.GA2038@deviant.kiev.zoral.com.ua> Message-ID: References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> <20080829190506.GA2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: davidxu@freebsd.org, Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 15:32:38 -0000 On Fri, 29 Aug 2008, Kostik Belousov wrote: > On Fri, Aug 29, 2008 at 12:25:09PM -0400, Daniel Eischen wrote: >> On Fri, 29 Aug 2008, Kostik Belousov wrote: >> >>> On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: >>>> >>>> Kostik, thanks! >>>> >>>> on 29/08/2008 17:10 Kostik Belousov said the following: >>>>> I am wondering why did you not fixed it youself with all this >>>>> information. >>>> >>>> I am wondering that myself now :-) >>>> I got bogged in rtld details and simply didn't think about the solution >>>> of doing setthreaded earlier. >>>> >>>> I will try your patch a couple of hours later. >>>> BTW, a forward question - should this patch help in the case of an >>>> exception thrown (and caught) before main(), i.e. in constructors of >>>> static/global objects? >>> If the objects are from the executable, then yes. I do not know about >>> present situation, but some time ago g++ and several other compilers >>> called ctr for global objects from the main() function. Regardeless >>> of this, init for main executable shall be called after init for >>> dependencies is finished. See initlist_add_objects(). >>> >>> On the other hand, ctr calls from linked dso may get fixed in regard >>> of exception throwing, or may not, depending on the relative order of >>> the dso loading against libthr. >>> >>>> >>>>> Anyway, patch below seems to work for me. David may have an opinion on >>>>> the change. >>>>> >>>>> diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c >>>>> index f96bba9..785d610 100644 >>>>> --- a/lib/libthr/thread/thr_init.c >>>>> +++ b/lib/libthr/thread/thr_init.c >>>>> @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) >>>>> if (_thread_event_mask & TD_CREATE) >>>>> _thr_report_creation(curthread, curthread); >>>>> } >>>>> + >>>>> + if (_thr_isthreaded() == 0) >>>>> + _thr_setthreaded(1); >>>>> } >>>>> >>>>> /* >> >> I think the intent of __isthreaded (and _thr_setthreaded()) was >> to be set if there were more than 1 thread, not to indicate that >> the thread library has been initialized. > > As demonstrated by Andriy' example, we need _thr_rtld_init() be called > before any rtld locks are given chance to be acquired. _thr_rtld_init() > shall be protected from repeated invocation, and _thr_setthreaded() > implements exactly this. > > If calling _thr_setthreaded(1) has not quite right intent, could you, > please, suggest satisfying solution ? I'm not sure I _quite_ understand the problem, but why wouldn't you have the same potential problem with some other library (without libthread)? I'll have to go back and read the beginning of the thread - I just kinda came in at the end. -- DE From owner-freebsd-threads@FreeBSD.ORG Sat Aug 30 15:56:28 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA8010656C0; Sat, 30 Aug 2008 15:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 10B8F8FC0A; Sat, 30 Aug 2008 15:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZSoM-0003B7-82; Sat, 30 Aug 2008 18:56:26 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7UFuMk8078614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Aug 2008 18:56:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7UFuM9d002399; Sat, 30 Aug 2008 18:56:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7UFuMZb002397; Sat, 30 Aug 2008 18:56:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Aug 2008 18:56:22 +0300 From: Kostik Belousov To: Daniel Eischen Message-ID: <20080830155622.GF2038@deviant.kiev.zoral.com.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> <20080829190506.GA2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sD87aq2/Ee9ozic7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZSoM-0003B7-82 a8d92eb016bf03b07cb6b30023912682 X-Terabit: YES Cc: davidxu@freebsd.org, Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 15:56:28 -0000 --sD87aq2/Ee9ozic7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote: > On Fri, 29 Aug 2008, Kostik Belousov wrote: >=20 > >On Fri, Aug 29, 2008 at 12:25:09PM -0400, Daniel Eischen wrote: > >>On Fri, 29 Aug 2008, Kostik Belousov wrote: > >> > >>>On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: > >>>> > >>>>Kostik, thanks! > >>>> > >>>>on 29/08/2008 17:10 Kostik Belousov said the following: > >>>>>I am wondering why did you not fixed it youself with all this > >>>>>information. > >>>> > >>>>I am wondering that myself now :-) > >>>>I got bogged in rtld details and simply didn't think about the soluti= on > >>>>of doing setthreaded earlier. > >>>> > >>>>I will try your patch a couple of hours later. > >>>>BTW, a forward question - should this patch help in the case of an > >>>>exception thrown (and caught) before main(), i.e. in constructors of > >>>>static/global objects? > >>>If the objects are from the executable, then yes. I do not know about > >>>present situation, but some time ago g++ and several other compilers > >>>called ctr for global objects from the main() function. Regardeless > >>>of this, init for main executable shall be called after init for > >>>dependencies is finished. See initlist_add_objects(). > >>> > >>>On the other hand, ctr calls from linked dso may get fixed in regard > >>>of exception throwing, or may not, depending on the relative order of > >>>the dso loading against libthr. > >>> > >>>> > >>>>>Anyway, patch below seems to work for me. David may have an opinion = on > >>>>>the change. > >>>>> > >>>>>diff --git a/lib/libthr/thread/thr_init.c=20 > >>>>>b/lib/libthr/thread/thr_init.c > >>>>>index f96bba9..785d610 100644 > >>>>>--- a/lib/libthr/thread/thr_init.c > >>>>>+++ b/lib/libthr/thread/thr_init.c > >>>>>@@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) > >>>>> if (_thread_event_mask & TD_CREATE) > >>>>> _thr_report_creation(curthread, curthread); > >>>>> } > >>>>>+ > >>>>>+ if (_thr_isthreaded() =3D=3D 0) > >>>>>+ _thr_setthreaded(1); > >>>>>} > >>>>> > >>>>>/* > >> > >>I think the intent of __isthreaded (and _thr_setthreaded()) was > >>to be set if there were more than 1 thread, not to indicate that > >>the thread library has been initialized. > > > >As demonstrated by Andriy' example, we need _thr_rtld_init() be called > >before any rtld locks are given chance to be acquired. _thr_rtld_init() > >shall be protected from repeated invocation, and _thr_setthreaded() > >implements exactly this. > > > >If calling _thr_setthreaded(1) has not quite right intent, could you, > >please, suggest satisfying solution ? >=20 > I'm not sure I _quite_ understand the problem, but why > wouldn't you have the same potential problem with some > other library (without libthread)? I'll have to go back > and read the beginning of the thread - I just kinda came > in at the end. Sure, for appropriate value of any. If you mean whether the same problem would arise for any threading library that supplies locking implementation for rtld, then certainly yes. I looked over and patched only libthr since this is the only survived library for now. Anyway, I do not insist on the proposed solution, and definitely prefer the change that is well aligned with libthr architecture. --sD87aq2/Ee9ozic7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki5baUACgkQC3+MBN1Mb4ga9gCeNbQi4PbFTFPwniFlJVkzHB5c CasAn3wGRFZ6znpjR5HqAYwu6ffuWrTI =63Dm -----END PGP SIGNATURE----- --sD87aq2/Ee9ozic7-- From owner-freebsd-threads@FreeBSD.ORG Sat Aug 30 16:15:33 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BFC106564A; Sat, 30 Aug 2008 16:15:33 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id DC1D48FC1C; Sat, 30 Aug 2008 16:15:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m7UGFVrt004742; Sat, 30 Aug 2008 12:15:31 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Sat, 30 Aug 2008 12:15:31 -0400 (EDT) Date: Sat, 30 Aug 2008 12:15:31 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kostik Belousov In-Reply-To: <20080830155622.GF2038@deviant.kiev.zoral.com.ua> Message-ID: References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> <20080829190506.GA2038@deviant.kiev.zoral.com.ua> <20080830155622.GF2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: davidxu@freebsd.org, Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 16:15:33 -0000 On Sat, 30 Aug 2008, Kostik Belousov wrote: > On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote: >> On Fri, 29 Aug 2008, Kostik Belousov wrote: >>> >>> As demonstrated by Andriy' example, we need _thr_rtld_init() be called >>> before any rtld locks are given chance to be acquired. _thr_rtld_init() >>> shall be protected from repeated invocation, and _thr_setthreaded() >>> implements exactly this. >>> >>> If calling _thr_setthreaded(1) has not quite right intent, could you, >>> please, suggest satisfying solution ? >> >> I'm not sure I _quite_ understand the problem, but why >> wouldn't you have the same potential problem with some >> other library (without libthread)? I'll have to go back >> and read the beginning of the thread - I just kinda came >> in at the end. > > Sure, for appropriate value of any. If you mean whether the same problem > would arise for any threading library that supplies locking implementation > for rtld, then certainly yes. I looked over and patched only libthr > since this is the only survived library for now. What I mean is, is fixing libthr a solution that will work for cases? Or, is libthr doing something wrong? I can't really see that it is. libthr assumes that everything is single-threaded (or serialized, I guess) before a thread is created. I am looking at this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=5235+0+current/freebsd-threads Where is the corresponding unlock for the wlock_acquire()? I guess this is the problem. When would this normally be released (without libthr being linked in)? Also, the __isthreaded flag is used in libc to avoid taking locks unless necessary. So if you have a single threaded application that is also linked with libthr, you don't pay the penalty of locking overhead. Lots of 3rd-party libraries link with a threads library, so an application may not even know it is "threaded". > > Anyway, I do not insist on the proposed solution, and definitely > prefer the change that is well aligned with libthr architecture. I'm not arguing anything, I just don't know that the problem lies within lib. Of course, the rtld init stuff could be pulled out and done in thread initialization instead of thr_setthreaded(). That doesn't leave much in thr_setthreaded, and it also adds locking overhead into rtld for single-threaded programs that are linked with libthr... -- DE From owner-freebsd-threads@FreeBSD.ORG Sat Aug 30 18:45:17 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7BC01065678; Sat, 30 Aug 2008 18:45:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4468FC19; Sat, 30 Aug 2008 18:45:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZVRk-000Eg2-A0; Sat, 30 Aug 2008 21:45:16 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7UIjDbh084376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Aug 2008 21:45:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7UIjDwi072931; Sat, 30 Aug 2008 21:45:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7UIjDmo072930; Sat, 30 Aug 2008 21:45:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Aug 2008 21:45:13 +0300 From: Kostik Belousov To: Daniel Eischen Message-ID: <20080830184512.GH2038@deviant.kiev.zoral.com.ua> References: <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> <20080829190506.GA2038@deviant.kiev.zoral.com.ua> <20080830155622.GF2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vqZEy/DEMZDTzjXG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZVRk-000Eg2-A0 94f6cb838be70e05bfd9e13151ddad01 X-Terabit: YES Cc: davidxu@freebsd.org, Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 18:45:17 -0000 --vqZEy/DEMZDTzjXG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2008 at 12:15:31PM -0400, Daniel Eischen wrote: > On Sat, 30 Aug 2008, Kostik Belousov wrote: >=20 > >On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote: > >>On Fri, 29 Aug 2008, Kostik Belousov wrote: > >>> > >>>As demonstrated by Andriy' example, we need _thr_rtld_init() be called > >>>before any rtld locks are given chance to be acquired. _thr_rtld_init() > >>>shall be protected from repeated invocation, and _thr_setthreaded() > >>>implements exactly this. > >>> > >>>If calling _thr_setthreaded(1) has not quite right intent, could you, > >>>please, suggest satisfying solution ? > >> > >>I'm not sure I _quite_ understand the problem, but why > >>wouldn't you have the same potential problem with some > >>other library (without libthread)? I'll have to go back > >>and read the beginning of the thread - I just kinda came > >>in at the end. > > > >Sure, for appropriate value of any. If you mean whether the same problem > >would arise for any threading library that supplies locking implementati= on > >for rtld, then certainly yes. I looked over and patched only libthr > >since this is the only survived library for now. >=20 > What I mean is, is fixing libthr a solution that will work > for cases? Or, is libthr doing something wrong? I can't > really see that it is. >=20 > libthr assumes that everything is single-threaded (or > serialized, I guess) before a thread is created. I > am looking at this thread: >=20 > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D5235+0+current/freebsd-t= hreads >=20 > Where is the corresponding unlock for the wlock_acquire()? > I guess this is the problem. When would this normally > be released (without libthr being linked in)? >=20 > Also, the __isthreaded flag is used in libc to avoid taking > locks unless necessary. So if you have a single threaded > application that is also linked with libthr, you don't > pay the penalty of locking overhead. Lots of 3rd-party > libraries link with a threads library, so an application > may not even know it is "threaded". >=20 > > > >Anyway, I do not insist on the proposed solution, and definitely > >prefer the change that is well aligned with libthr architecture. >=20 > I'm not arguing anything, I just don't know that the problem > lies within lib. Of course, the > rtld init stuff could be pulled out and done in thread > initialization instead of thr_setthreaded(). That doesn't > leave much in thr_setthreaded, and it also adds locking > overhead into rtld for single-threaded programs that are > linked with libthr... Ok, let me to tell the whole story. I am sure that in fact you know it better then me. Assuming libthr is the only threading library, there are two locking implementations for the rtld: 'default' and the one supplied by libthr. On the first call to pthread_create(), libthr calls _rtld_thread_init() to substitute the default by the implementation from libthr. In fact, default implementation is broken from my point of view. For instance, thread_flag update is not atomic. Moreover, it does not correctly handles sequential acquision of several locks, due to thread_flag. The dl_iterate_phdr() function, called by gcc exception handling support code, does exactly this. It acquires rtld_phdr_lock, then rtld_bind_lock. [I shall admit it does this after my change]. In particular, this would leave the bit for the bind lock set in the thread_flag. Andriy' example throw the exception and calls dl_iterate_phdr() before first thread is created. On thread creation, _rtld_thread_init() is called, that tries to move the locks according to thread_flag. This is the cause for the reported wlock acquisition. I do not want to change anything in the default rtld locking. It is disfunctional from the time libc_r is gone, and I think it would be better to make it nop. My change makes the image that is linked with libthr, to consistently use libthr locks. --vqZEy/DEMZDTzjXG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki5lTgACgkQC3+MBN1Mb4j46wCgt5gz5qRSbHMdcx84LycxOFGT TP0AnRwctq3U++n1yqPYPY/qYqrb0rKN =RFyX -----END PGP SIGNATURE----- --vqZEy/DEMZDTzjXG--