From dfilter at FreeBSD.ORG Fri Aug 1 01:30:04 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Aug 1 01:30:10 2008 Subject: kern/126128: commit references a PR Message-ID: <200808010130.m711U4PQ006868@freefall.freebsd.org> The following reply was made to PR kern/126128; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126128: commit references a PR Date: Fri, 1 Aug 2008 01:22:08 +0000 (UTC) davidxu 2008-08-01 01:21:49 UTC FreeBSD src repository Modified files: lib/libthr/thread thr_condattr.c Log: SVN rev 181099 on 2008-08-01 01:21:49Z by davidxu In function pthread_condattr_getpshared, store result correctly. PR: kern/126128 Revision Changes Path 1.4 +1 -1 src/lib/libthr/thread/thr_condattr.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From mo0118 at gmail.com Sat Aug 2 20:23:38 2008 From: mo0118 at gmail.com (Jeff Mo) Date: Sat Aug 2 20:23:47 2008 Subject: Need Help on "threads/110306: apache 2.0 segmentation violation when calling gethostbyname" Message-ID: Hi , Can anyone nicely explain a little bit about what does "ServerName is not defined in httpd.conf." mean in the following sentence from bug description? "The problem happens if php module is loaded and ServerName is not defined in httpd.conf." Thank you very much Jeff From ivoras at freebsd.org Mon Aug 4 05:05:02 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Aug 4 05:05:09 2008 Subject: Need Help on "threads/110306: apache 2.0 segmentation violation when calling gethostbyname" In-Reply-To: References: Message-ID: Jeff Mo wrote: > Hi , > > Can anyone nicely explain a little bit about what does "ServerName is not > defined > in httpd.conf." mean in the following sentence from bug description? > > "The problem happens if php module is loaded and ServerName is not defined > in httpd.conf." You are not looking for the trivial answer? ("ServerName" is a configuration item in httpd.conf). If ServerName is not set, Apache will try to guess the host's FQDN by various tricks, including reverse DNS lookup on its IP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080804/6b9c7eea/signature.pgp From bugmaster at FreeBSD.org Mon Aug 4 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:09:03 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200808041107.m74B73SR082225@freefall.freebsd.org> 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 dixit at netapp.com Mon Aug 4 19:39:39 2008 From: dixit at netapp.com (Dixit, Amol) Date: Mon Aug 4 19:39:45 2008 Subject: libpthread and gdbserver In-Reply-To: <488A213F.70105@netapp.com> References: <488A213F.70105@netapp.com> Message-ID: <48975AF9.3060204@netapp.com> Hi, I am now linking my sample application with libthr instead of libpthread, as libthr is the default going forward and it got me past issues in my previous mail (below). I had a question regarding FreeBsd libthread_db. In libthr_db_ops vector (libthr_db.c), we have pt_ta_map_id2thr() and pt_ta_map_lwp2thr(). The former maps tid to thread_handle and latter maps pid to tid. But pt_ta_map_lwp2thr() internally calls pt_ta_map_id2thr() in libthr_db.c so 'pid to tid' conversion is missing. If FreeBsd intends to keep it this way, I will have to modify gdbserver to not use 'pid' to find threads as Linux does. Can someone shed some light on this? Am I mailing the correct mailing-list with these queries? Thanks, Amol Dixit, Amol wrote: > Hi, > I am attempting to port gdbserver to freebsd (initially only for x86 & > libpthread) and I need some assistance with libpthread and libthread-db. > (i) From the code looks like libpthread does not provide any 'thread > creation event' symbol/address to be looked up by thread-db. I got > around this by adding a dummy function call before _thread_create > returned, and that new symbol can be used by thread-db to set > thread-creation breakpoint (analogous to _thread_bp_create in libthr). > (ii) Next hurdle is the race between thread-db and libpthread. > Thread-db tries to access '_thread_list' which is maintained in > libpthread and will eventually contain the 'initial thread' but this > list is NULL when thread-db tries to access it early. There is a > comment before _pthread_create() "It'd be nice to automatically have > _libpthread_init called on program execution..." which will be helpful > for thread-db. Currently I am stuck here as thread-db cannot enable > threading early enough since libpthread is assigning 'initial thread' > to '_thread_list' lazily. > > Am I on the right track on above issues? Any work going on in this area? > Really appreciate any help on this project. > > Thanks, > Amol > > > _______________________________________________ > 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 bugmaster at FreeBSD.org Mon Aug 11 11:07:10 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:09:01 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200808111107.m7BB7AVI047352@freefall.freebsd.org> 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 bugmaster at FreeBSD.org Mon Aug 18 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:09:01 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200808181106.m7IB6wHS079969@freefall.freebsd.org> 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 bugmaster at FreeBSD.org Mon Aug 25 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:09:08 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200808251106.m7PB6wJI027916@freefall.freebsd.org> 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 avg at icyb.net.ua Thu Aug 28 20:52:50 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Aug 28 20:52:57 2008 Subject: mysterious hang in pthread_create In-Reply-To: <48B70A98.5060501@icyb.net.ua> References: <48B70A98.5060501@icyb.net.ua> Message-ID: <48B7101E.7060203@icyb.net.ua> 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 avg at icyb.net.ua Thu Aug 28 21:14:20 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Aug 28 21:14:26 2008 Subject: mysterious hang in pthread_create Message-ID: <48B70A98.5060501@icyb.net.ua> 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 avg at icyb.net.ua Thu Aug 28 21:42:02 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Aug 28 21:42:08 2008 Subject: mysterious hang in pthread_create In-Reply-To: <48B7101E.7060203@icyb.net.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> Message-ID: <48B71BA6.5040504@icyb.net.ua> 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 jhein at timing.com Fri Aug 29 13:41:59 2008 From: jhein at timing.com (John Hein) Date: Fri Aug 29 13:42:06 2008 Subject: mysterious hang in pthread_create In-Reply-To: <48B71BA6.5040504@icyb.net.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> Message-ID: <18615.62453.623443.27126@gromit.timing.com> 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 kostikbel at gmail.com Fri Aug 29 14:34:10 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Aug 29 14:34:17 2008 Subject: mysterious hang in pthread_create In-Reply-To: <48B71BA6.5040504@icyb.net.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> Message-ID: <20080829141043.GX2038@deviant.kiev.zoral.com.ua> 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 > >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 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() == 0) + _thr_setthreaded(1); } /* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080829/d775367c/attachment.pgp From kostikbel at gmail.com Fri Aug 29 14:36:52 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Aug 29 14:36:58 2008 Subject: mysterious hang in pthread_create In-Reply-To: <48B8052A.6070908@icyb.net.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> Message-ID: <20080829143645.GY2038@deviant.kiev.zoral.com.ua> 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); > > } > > > > /* > > > -- > Andriy Gapon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080829/3a3a3777/attachment.pgp From avg at icyb.net.ua Fri Aug 29 14:46:16 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Aug 29 14:46:28 2008 Subject: mysterious hang in pthread_create In-Reply-To: <20080829141043.GX2038@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> Message-ID: <48B8052A.6070908@icyb.net.ua> 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 agile at sunbay.com Fri Aug 29 14:50:15 2008 From: agile at sunbay.com (Oleg Dolgov) Date: Fri Aug 29 14:50:22 2008 Subject: threads/126950: rtld malloc is thread-unsafe Message-ID: <200808291448.m7TEmPbg020616@www.freebsd.org> >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 deischen at freebsd.org Fri Aug 29 16:47:06 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Fri Aug 29 16:47:12 2008 Subject: mysterious hang in pthread_create In-Reply-To: <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> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> Message-ID: 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 kabaev at gmail.com Fri Aug 29 18:40:03 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Fri Aug 29 18:40:10 2008 Subject: threads/126950: rtld malloc is thread-unsafe Message-ID: <200808291840.m7TIe3in002358@freefall.freebsd.org> 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 kostikbel at gmail.com Fri Aug 29 19:05:11 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Aug 29 19:05:19 2008 Subject: mysterious hang in pthread_create In-Reply-To: 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> Message-ID: <20080829190506.GA2038@deviant.kiev.zoral.com.ua> 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 ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080829/7cde3bc4/attachment.pgp From kmacy at freebsd.org Fri Aug 29 22:10:05 2008 From: kmacy at freebsd.org (Kip Macy) Date: Fri Aug 29 22:10:15 2008 Subject: threads/126950: rtld malloc is thread-unsafe Message-ID: <200808292210.m7TMA53f019709@freefall.freebsd.org> 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 agile at sunbay.com Fri Aug 29 23:30:04 2008 From: agile at sunbay.com (agile@sunbay.com) Date: Fri Aug 29 23:30:11 2008 Subject: threads/126950: rtld malloc is thread-unsafe Message-ID: <200808292330.m7TNU4Yu027171@freefall.freebsd.org> 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 kostikbel at gmail.com Sat Aug 30 08:30:31 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 30 08:30:38 2008 Subject: threads/126950: rtld malloc is thread-unsafe In-Reply-To: <200808292210.m7TMA53f019709@freefall.freebsd.org> References: <200808292210.m7TMA53f019709@freefall.freebsd.org> Message-ID: <20080830083027.GD2038@deviant.kiev.zoral.com.ua> 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 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. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080830/10cd919c/attachment.pgp From deischen at freebsd.org Sat Aug 30 15:32:38 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Aug 30 15:32:45 2008 Subject: mysterious hang in pthread_create In-Reply-To: <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> <20080829190506.GA2038@deviant.kiev.zoral.com.ua> Message-ID: 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 kostikbel at gmail.com Sat Aug 30 15:56:28 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 30 15:56:35 2008 Subject: mysterious hang in pthread_create In-Reply-To: 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> Message-ID: <20080830155622.GF2038@deviant.kiev.zoral.com.ua> On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote: > 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. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080830/9a6e69da/attachment.pgp From deischen at freebsd.org Sat Aug 30 16:15:33 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Aug 30 16:15:40 2008 Subject: mysterious hang in pthread_create In-Reply-To: <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> <20080830155622.GF2038@deviant.kiev.zoral.com.ua> Message-ID: 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 kostikbel at gmail.com Sat Aug 30 18:45:17 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 30 18:45:24 2008 Subject: mysterious hang in pthread_create In-Reply-To: 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> Message-ID: <20080830184512.GH2038@deviant.kiev.zoral.com.ua> On Sat, Aug 30, 2008 at 12:15:31PM -0400, Daniel Eischen wrote: > 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... 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080830/c45e33a3/attachment.pgp From deischen at freebsd.org Sun Aug 31 15:39:54 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Sun Aug 31 15:40:01 2008 Subject: mysterious hang in pthread_create In-Reply-To: <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> <20080830184512.GH2038@deviant.kiev.zoral.com.ua> Message-ID: On Sat, 30 Aug 2008, Kostik Belousov wrote: > On Sat, Aug 30, 2008 at 12:15:31PM -0400, Daniel Eischen wrote: >> 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... > > 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. What happens if you remove the thread_flag() stuff (support for libc_r?) from rtld? It seems that libc_r should be providing its own rtld locking hooks - just like libthr does. -- DE From kostikbel at gmail.com Sun Aug 31 18:27:14 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Aug 31 18:27:25 2008 Subject: mysterious hang in pthread_create In-Reply-To: References: <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> <20080830184512.GH2038@deviant.kiev.zoral.com.ua> Message-ID: <20080831182708.GN2038@deviant.kiev.zoral.com.ua> On Sun, Aug 31, 2008 at 11:39:52AM -0400, Daniel Eischen wrote: > On Sat, 30 Aug 2008, Kostik Belousov wrote: > > >On Sat, Aug 30, 2008 at 12:15:31PM -0400, Daniel Eischen wrote: > >>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... > > > >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. > > What happens if you remove the thread_flag() stuff (support > for libc_r?) from rtld? It seems that libc_r should be providing > its own rtld locking hooks - just like libthr does. No, libc_r uses default rtld locking, as absence of the references to _rtld_thread_init in libc_r code indicates. This is one of the reasons why I decline to change the code. We still support compat-4.x on all supported systems, but I have no way to properly test it, If changing the default implementation, I think we should just record lock attempts to be able to transfer them when _rtld_thread_init is called. But this would break libc_r. I saw the use of the libthr locking from the start as the cleanest and least intrusive. As I said, I would gladly accept any better idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080831/216801a4/attachment.pgp