From owner-freebsd-threads@FreeBSD.ORG Mon Oct 4 11:07:07 2010 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 49A3E1065670 for ; Mon, 4 Oct 2010 11:07:07 +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 2D7E18FC1B for ; Mon, 4 Oct 2010 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o94B77Jp065974 for ; Mon, 4 Oct 2010 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o94B766v065972 for freebsd-threads@FreeBSD.org; Mon, 4 Oct 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Oct 2010 11:07:06 GMT Message-Id: <201010041107.o94B766v065972@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, 04 Oct 2010 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 37 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Oct 6 18:13:58 2010 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 164D8106566B for ; Wed, 6 Oct 2010 18:13:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0C38FC1D for ; Wed, 6 Oct 2010 18:13:57 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0536B3F5B6 for ; Wed, 6 Oct 2010 17:56:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o96Hu9KK051323 for ; Wed, 6 Oct 2010 17:56:09 GMT (envelope-from phk@critter.freebsd.dk) To: threads@freebsd.org From: Poul-Henning Kamp Date: Wed, 06 Oct 2010 17:56:09 +0000 Message-ID: <51322.1286387769@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: suspect problems on -current with pthread_cond_*() 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: Wed, 06 Oct 2010 18:13:58 -0000 Hi Guys, I updated my machine to current (9.0-CURRENT #0 r213377M: Mon Oct 4) (previous version from april sometime) and have started to see weird new problems with Varnish regression tests. It's pretty hard to get a trace on the problem, but from what I have found out until now, it is related to the very first operation(s) on a pthread_cond_t and the typical indication is a 100% cpu-spin inside libthr. I can reproduce the problem in approx 5 minutes by running the automated Varnish regression tests in >=8 parallel streams repeatedly[1] but due to the nature/complexity of varnish, I have not been able to get a debugger to give me a useful backtrace yet. I only use pthread_cond_t's in two isolated places and I am going to muck about with them now, to see if I can affect the issue in any way (higher/lower failure rate etc). Any insights ? Poul-Henning PS: I'll arrive in Karlsruhe friday morning... [1] It is an easy test to set up: svn co http://www.varnish-cache.org/svn/trunk cd trunk/varnish-cache sh autogen.des make cd varnish-cache/bin/varnishtest while gmake -j 12 -f Makefile.kristian check do true done Look for test-failures with "HTTP rx failed (poll: Unknown error: 0)" A couple of the test cases may fail under high load for other reasons, in particular m00001.vtc and c00002.vtc. The varnishtest driver program can also be hit, but this happens much more seldom, that usually leaves a core dump with a useless backtrace. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.