From owner-freebsd-threads@FreeBSD.ORG Sun Apr 20 04:20:01 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 76589106566C for ; Sun, 20 Apr 2008 04:20:01 +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 54E408FC19 for ; Sun, 20 Apr 2008 04:20:01 +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 m3K4K1A2027254 for ; Sun, 20 Apr 2008 04:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3K4K1Y7027253; Sun, 20 Apr 2008 04:20:01 GMT (envelope-from gnats) Resent-Date: Sun, 20 Apr 2008 04:20:01 GMT Resent-Message-Id: <200804200420.m3K4K1Y7027253@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, bob frazier Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D214B106566B for ; Sun, 20 Apr 2008 04:12:49 +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 C21FC8FC17 for ; Sun, 20 Apr 2008 04:12:49 +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 m3K4CWlk005360 for ; Sun, 20 Apr 2008 04:12:32 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m3K4CWMI005359; Sun, 20 Apr 2008 04:12:32 GMT (envelope-from nobody) Message-Id: <200804200412.m3K4CWMI005359@www.freebsd.org> Date: Sun, 20 Apr 2008 04:12:32 GMT From: bob frazier To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/122923: 'nice' does not prevent background process from stealing CPU from foreground 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: Sun, 20 Apr 2008 04:20:01 -0000 >Number: 122923 >Category: threads >Synopsis: 'nice' does not prevent background process from stealing CPU from foreground >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 20 04:20:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: bob frazier >Release: 7-STABLE >Organization: SFT Inc. >Environment: FreeBSD hack.SFT.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr 1 01:11:09 PDT 2008 root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC i386 >Description: When a background process that is CPU intensive is 'renice'd to 19, it will still affect foreground processes (such as watching a movie with vlc) such that 'stuttering' or obvious lapses in process scheduling can easily be observed. Removing the background process entirely alleviates the 'intermittent response' or 'stuttering' problem. In its worst state the 'stuttering' seems to allow about 1/2 second 'bursts' of CPU for the foreground, then the background process, then the foreground again, when CPU utilization in the foreground approaches the 100% mark (like decoding an H.264 movie). Using 'idprio' to TRULY move the background process into the background can make it possible to leave the background process running and NOT cause significant performance problems in the foreground. However, the behavior I describe here did NOT exist in 6.3 and should not require this kind of workaround. In my search for similar bug reports, I found a behavior described in 'ports/118645' where mouse response was 'intermittent' or 'stuttering' while a background process used a lot of CPU. I have also observed this particular mouse behavior on rare occasions, once precedeeding a system crash (see kern/122615). >How-To-Repeat: a) run a CPU-intensive process with 'nice 19' (such as 'dnetc' from ports), one that does not already move itself into an 'idle priority' class. b) run the 'XAnalogTV' x screensaver under X11. Observe intermittent display updates. [Alternately play a video with vlc that requires >50% cpu to decode, ideally with divx or h.264 encoding] c) use 'idprio' to move the dnetc process into one of the lowest possible priority classes (idle 30) d) run the 'XAnalogTV' screensaver (or video) again >Fix: A workaround can be achieved by using 'idprio' to move the background process into the idle priority class as described above. This appears to have the same effect on the process that 'renice 19' had in 6.3 . >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 11:06:57 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 623CB106564A for ; Mon, 21 Apr 2008 11:06:57 +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 509BF8FC23 for ; Mon, 21 Apr 2008 11:06:57 +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 m3LB6v8j095332 for ; Mon, 21 Apr 2008 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3LB6uBE095328 for freebsd-threads@FreeBSD.org; Mon, 21 Apr 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2008 11:06:56 GMT Message-Id: <200804211106.m3LB6uBE095328@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, 21 Apr 2008 11:06:57 -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 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 unexpected and unreliable behaviour when using SYSV se 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 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri Apr 25 01:10: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 194D2106567A for ; Fri, 25 Apr 2008 01:10: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 077778FC14 for ; Fri, 25 Apr 2008 01:10: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 m3P1A2Lf081361 for ; Fri, 25 Apr 2008 01:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3P1A2v1081360; Fri, 25 Apr 2008 01:10:02 GMT (envelope-from gnats) Resent-Date: Fri, 25 Apr 2008 01:10:02 GMT Resent-Message-Id: <200804250110.m3P1A2v1081360@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, Andy Newman Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2114F1065675 for ; Fri, 25 Apr 2008 01:04:04 +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 20E128FC0A for ; Fri, 25 Apr 2008 01:04:04 +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 m3P13ZNB073975 for ; Fri, 25 Apr 2008 01:03:35 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m3P13ZmU073974; Fri, 25 Apr 2008 01:03:35 GMT (envelope-from nobody) Message-Id: <200804250103.m3P13ZmU073974@www.freebsd.org> Date: Fri, 25 Apr 2008 01:03:35 GMT From: Andy Newman To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/123062: C++ exception handling can loop during stacking unwinding in multithreaded programs 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, 25 Apr 2008 01:10:03 -0000 >Number: 123062 >Category: threads >Synopsis: C++ exception handling can loop during stacking unwinding in multithreaded programs >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 Apr 25 01:10:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Andy Newman >Release: 7-STABLE >Organization: >Environment: FreeBSD juju.bsn 7.0-STABLE FreeBSD 7.0-STABLE #22: Fri Apr 18 20:18:44 EST 2008 root@juju.local:/usr/obj/usr/src/sys/JUJU i386 >Description: The gcc runtime's _Unwind_Find_FDE function, invoked during exception handling's stack unwinding, is not safe to execute from within multiple threads. FreeBSD's dl_iterate_phdr() however permits multiple threads to pass through it though. The result is surprisingly reliable infinite looping of one or more threads if they just happen to be unwinding at the same time. A bug report to gcc (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36030), with a fix to _Unwind_Find_FDE to protect its cache manipulations, has the response that glibc's dl_iterate_phdr doesn't let multiple threads unwind at the same time. To that end here's a patch to ld-elf.so that adds a lock around the dl_iterate_pdr call (well, within it) that has it operate in the same way as glibc's and avoid the looping problem. >How-To-Repeat: Reproduction is via the small program attached to the gcc bug report. As described there, the program creates some number of threads, each of which immediately throws an exception. The exceptions are caught and ignored in the thread. The threads are then joined and the program exits. Failure does not occur every time due to the usual race condition issues however by running the program in a shell loop it will eventually lock up attempting to join the threads. Some number of threads will be looping consuming 100% CPU. This has been tested on multiprocessor machines (two and four way) will reliable behavior. >Fix: Apply the attached patch and re-run tests. No failures have been observed over hundreds of thousands of runs. The patch adds another lock to ld-elf.so used solely to stop multiple threads running dl_iterate_pdr() at the same time. At entry the lock is obtained (as a write lock), the iteration performed and then the lock is released. Note that simply upgrading the existing read lock (rtld_bind_lock) to a write lock does not work and results in deadlock presumably due to other rtld functions being called during the stack unwinding which want to obtain the "bind" lock. Patch attached with submission follows: Index: rtld.c =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v retrieving revision 1.124 diff -u -r1.124 rtld.c --- rtld.c 17 May 2007 18:00:27 -0000 1.124 +++ rtld.c 25 Apr 2008 00:34:54 -0000 @@ -2100,7 +2100,7 @@ const Obj_Entry *obj; int error, lockstate; - lockstate = rlock_acquire(rtld_bind_lock); + lockstate = wlock_acquire(rtld_phdr_lock); error = 0; @@ -2119,7 +2119,7 @@ break; } - rlock_release(rtld_bind_lock, lockstate); + wlock_release(rtld_phdr_lock, lockstate); return (error); } Index: rtld_lock.c =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/rtld_lock.c,v retrieving revision 1.4 diff -u -r1.4 rtld_lock.c --- rtld_lock.c 3 Apr 2007 18:28:13 -0000 1.4 +++ rtld_lock.c 24 Apr 2008 13:55:04 -0000 @@ -171,7 +171,7 @@ lockinfo.thread_clr_flag(mask); } -#define RTLD_LOCK_CNT 2 +#define RTLD_LOCK_CNT 3 struct rtld_lock { void *handle; int mask; @@ -179,6 +179,7 @@ rtld_lock_t rtld_bind_lock = &rtld_locks[0]; rtld_lock_t rtld_libc_lock = &rtld_locks[1]; +rtld_lock_t rtld_phdr_lock = &rtld_locks[2]; int rlock_acquire(rtld_lock_t lock) Index: rtld_lock.h =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/rtld_lock.h,v retrieving revision 1.2 diff -u -r1.2 rtld_lock.h --- rtld_lock.h 19 Jun 2003 02:39:37 -0000 1.2 +++ rtld_lock.h 24 Apr 2008 13:55:16 -0000 @@ -52,6 +52,7 @@ extern rtld_lock_t rtld_bind_lock; extern rtld_lock_t rtld_libc_lock; +extern rtld_lock_t rtld_phdr_lock; int rlock_acquire(rtld_lock_t); int wlock_acquire(rtld_lock_t); >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Sat Apr 26 18:00:19 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 CF4DE1065689 for ; Sat, 26 Apr 2008 18:00:19 +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 C0B8E8FC27 for ; Sat, 26 Apr 2008 18:00:19 +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 m3QI0JlF095690 for ; Sat, 26 Apr 2008 18:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3QI0Jqo095689; Sat, 26 Apr 2008 18:00:19 GMT (envelope-from gnats) Date: Sat, 26 Apr 2008 18:00:19 GMT Message-Id: <200804261800.m3QI0Jqo095689@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Alexander Kabaev Cc: Subject: Re: threads/123062: C++ exception handling can loop during stacking unwinding in multithreaded programs 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: Sat, 26 Apr 2008 18:00:19 -0000 The following reply was made to PR threads/123062; it has been noted by GNATS. From: Alexander Kabaev To: bug-followup@FreeBSD.org, an@atrn.org Cc: Subject: Re: threads/123062: C++ exception handling can loop during stacking unwinding in multithreaded programs Date: Sat, 26 Apr 2008 13:31:59 -0400 --Sig_/jE_NPZ+k9d60EUGxgQP9P0/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The submitted patch is obviously incorrect. If you are adding rtld_phdr_lock, you should be grabbing it in addition to rtld_bind_lock instead of replacing it. --=20 Alexander Kabaev --Sig_/jE_NPZ+k9d60EUGxgQP9P0/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIE2cPQ6z1jMm+XZYRAn/9AJ90LIyBxRqJ/nYsOLIk8AIgYmeOsACgtmGl kln3874RduXKUSKUMRDh1pU= =gflu -----END PGP SIGNATURE----- --Sig_/jE_NPZ+k9d60EUGxgQP9P0/--