From owner-freebsd-threads@FreeBSD.ORG Mon Jun 8 11:07:03 2009 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 7862B1065670 for ; Mon, 8 Jun 2009 11:07:03 +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 5BBF58FC15 for ; Mon, 8 Jun 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58B73eQ020829 for ; Mon, 8 Jun 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58B72WP020825 for freebsd-threads@FreeBSD.org; Mon, 8 Jun 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jun 2009 11:07:02 GMT Message-Id: <200906081107.n58B72WP020825@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, 08 Jun 2009 11:07:04 -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/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/118715 threads kse problem 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/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads 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 o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi 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 38 problems total. From owner-freebsd-threads@FreeBSD.ORG Thu Jun 11 02:10:02 2009 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 7B8C01065676 for ; Thu, 11 Jun 2009 02:10:02 +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 55FF78FC16 for ; Thu, 11 Jun 2009 02:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5B2A2wo041807 for ; Thu, 11 Jun 2009 02:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5B2A2KZ041806; Thu, 11 Jun 2009 02:10:02 GMT (envelope-from gnats) Resent-Date: Thu, 11 Jun 2009 02:10:02 GMT Resent-Message-Id: <200906110210.n5B2A2KZ041806@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, Marc Unangst Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D5A1065686 for ; Thu, 11 Jun 2009 02:03:52 +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 B52188FC0A for ; Thu, 11 Jun 2009 02:03:52 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n5B23qM6059128 for ; Thu, 11 Jun 2009 02:03:52 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n5B23qJ8059126; Thu, 11 Jun 2009 02:03:52 GMT (envelope-from nobody) Message-Id: <200906110203.n5B23qJ8059126@www.freebsd.org> Date: Thu, 11 Jun 2009 02:03:52 GMT From: Marc Unangst To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/135462: [PATCH] _thread_cleanupspecific() doesn't handle deleted keys X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 02:10:02 -0000 >Number: 135462 >Category: threads >Synopsis: [PATCH] _thread_cleanupspecific() doesn't handle deleted keys >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: Thu Jun 11 02:10:02 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Marc Unangst >Release: FreeBSD 7.0-RELEASE amd64 >Organization: Panasas, Inc. >Environment: FreeBSD perf-x4 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Programs that use thread-specific data occasionally exit with a warning like this: Thread 801202c70 has exited with leftover thread-specific data after 4 destructor iterations This occurs because the thread-specific data cleanup routine that runs when a thread exits (_thread_cleanupspecific()) doesn't handle cleaning up keys that were deleted via pthread_key_delete() while the exiting thread still had a non-NULL value set for that key. The test is if (_thread_keytable[key].allocated && (curthread->specific[key].data != NULL)) { i.e., if the key exists globally and the current thread has a non-NULL key. However, POSIX allows the application to delete the key without clearing the value in all threads; http://www.opengroup.org/onlinepubs/009695399/functions/pthread_key_delete.html says "The thread-specific data values associated with key need not be NULL at the time pthread_key_delete() is called." POSIX also specifies that in this case, the destructor routine (if one is defined) is not invoked. In this scenario, the cleanup routine should just set the thread-specific data value for that key to NULL and decrement curthread->specific_data_count. >How-To-Repeat: Compile and run the following program: /* * bug_93732.c * * @author mju * * Unit test for bug 93732. * * Compile like this: * gcc -Wall -pthread -o bug_93732 bug_93732.c */ #include #include #include #include #include void *test_thread(void *arg_ignored); int main(int argc, char **argv) { int ret; pthread_t thr; ret = pthread_create(&thr, NULL, test_thread, NULL); if (ret != 0) { fprintf(stderr, "pthread_create failed: %s\n", strerror(errno)); exit(1); } printf("Thread created, waiting for exit\n"); (void) pthread_join(thr, NULL); printf("Thread terminated, exiting\n"); exit(0); } void *test_thread(void *arg_ignored) { int ret; pthread_key_t key; int i = 2; ret = pthread_key_create(&key, NULL); if (ret != 0) { fprintf(stderr, "pthread_key_create failed: %s\n", strerror(errno)); exit(1); } printf("Created key %d\n", (int) key); ret = pthread_setspecific(key, &i); if (ret != 0) { fprintf(stderr, "pthread_setspecific failed: %s\n", strerror(errno)); exit(1); } printf("Set key to %p\n", &i); ret = pthread_key_delete(key); if (ret != 0) { fprintf(stderr, "pthread_key_delete failed: %s\n", strerror(errno)); exit(1); } printf("Deleted key %d\n", (int) key); return NULL; } >Fix: See attached patch file. Patch attached with submission follows: --- /net/paneast/sb7/mju/freebsd-svn/head/lib/libthr/thread/thr_spec.c 2009-05-26 17:45:27.000000000 -0400 +++ thr_spec.c 2009-06-10 14:57:06.000000000 -0400 @@ -131,9 +131,19 @@ curthread->specific[key].data = NULL; curthread->specific_data_count--; } + else if (curthread->specific[key].data != NULL) { + /* + * This can happen if the key is deleted via + * pthread_key_delete without first setting the value + * to NULL in all threads. POSIX says that the + * destructor is not invoked in this case. + */ + curthread->specific[key].data = NULL; + curthread->specific_data_count--; + } /* - * If there is a destructore, call it + * If there is a destructor, call it * with the key table entry unlocked: */ if (destructor != NULL) { >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Thu Jun 11 13:20:01 2009 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 7772D106566C for ; Thu, 11 Jun 2009 13: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 52B4D8FC1B for ; Thu, 11 Jun 2009 13: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.3/8.14.3) with ESMTP id n5BDK1iX000421 for ; Thu, 11 Jun 2009 13:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5BDK1eQ000420; Thu, 11 Jun 2009 13:20:01 GMT (envelope-from gnats) Resent-Date: Thu, 11 Jun 2009 13:20:01 GMT Resent-Message-Id: <200906111320.n5BDK1eQ000420@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, Jacques Caron Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1AD106564A for ; Thu, 11 Jun 2009 13:19: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 72CA88FC0C for ; Thu, 11 Jun 2009 13:19:04 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n5BDJ3Vj056434 for ; Thu, 11 Jun 2009 13:19:03 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n5BDJ3Bl056433; Thu, 11 Jun 2009 13:19:03 GMT (envelope-from nobody) Message-Id: <200906111319.n5BDJ3Bl056433@www.freebsd.org> Date: Thu, 11 Jun 2009 13:19:03 GMT From: Jacques Caron To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/135477: dlclose on shared object liked with libthr causes SIGSEGV X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:20:01 -0000 >Number: 135477 >Category: threads >Synopsis: dlclose on shared object liked with libthr causes SIGSEGV >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 11 13:20:00 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jacques Caron >Release: 7.1 >Organization: Oxado >Environment: FreeBSD DSVR009130.naxopay.com 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Jan 29 19:14:58 GMT 2009 jc@DSVR009130.naxopay.com:/usr/src/sys/i386/compile/CARP i386 >Description: When an application not linked with libthr dynamically loads a shared object linked with libthr (directly or indirectly), some libc stubs are replaced by their libthr equivalents. When the application unloads the same object, libthr is unloaded as well, but links towards libthr functions are left in place, which results in a crash as soon as those functions are called (often implicitly, by thread-protected functions in libc, e.g. gethostbyname). This happens for instance with apache 1.3 modules that are linked with a thread-enabled version of the postgresql client library (libpq). Restarting the server will quite often cause a crash. >How-To-Repeat: #!/bin/sh cat <test_load_module.c #include #include #include int main(int argc,char **argv) { void * handle; if (argc!=2) { printf("usage %s \n", argv[0]); return -1; } handle = dlopen(argv[1], RTLD_NOW); if (!handle) { printf("dlopen: %s\n",dlerror()); return -1; } gethostbyname("127.0.0.1"); dlclose(handle); gethostbyname("127.0.0.1"); printf("Everything went fine!\n"); return 0; } EOF cat <test_module.c void dummy(void) { } EOF cc -g -Wall -fpic -c test_module.c -o test_module.o cc -g -shared test_module.o -o test_module_no_thr.so cc -g -shared test_module.o -lthr -o test_module_thr.so cc -g -Wall test_load_module.c -o test_load_module_no_thr cc -g -Wall test_load_module.c -lthr -o test_load_module_thr echo "Main program no thr, module no thr" ./test_load_module_no_thr ./test_module_no_thr.so echo "Main program no thr, module thr" ./test_load_module_no_thr ./test_module_thr.so echo "Main program thr, module no thr" ./test_load_module_thr ./test_module_no_thr.so echo "Main program thr, module thr" ./test_load_module_thr ./test_module_thr.so >Fix: A workaround is to build the loading application with -lthr even if threads are not needed (this way libthr is not unloaded when the module is unloaded), or make sure that no loaded modules are linked (even indirectly) with -lthr. A fix would probably either: - prevent libthr from being dynamically unloaded once it has been loaded (probably the best option, but no idea how to achieve this) - restore links to the libc stubs if libthr is unloaded (via a _fini() function that will be called by dlclose). >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Thu Jun 11 13:56:52 2009 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 40DB31065679; Thu, 11 Jun 2009 13:56:52 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 15BD08FC1A; Thu, 11 Jun 2009 13:56:52 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (kib@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5BDuptd030172; Thu, 11 Jun 2009 13:56:51 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5BDuphT030168; Thu, 11 Jun 2009 13:56:51 GMT (envelope-from kib) Date: Thu, 11 Jun 2009 13:56:51 GMT Message-Id: <200906111356.n5BDuphT030168@freefall.freebsd.org> To: jc@oxado.com, kib@FreeBSD.org, freebsd-threads@FreeBSD.org From: kib@FreeBSD.org Cc: Subject: Re: threads/135477: dlclose on shared object liked with libthr causes SIGSEGV X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:56:53 -0000 Synopsis: dlclose on shared object liked with libthr causes SIGSEGV State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Thu Jun 11 13:54:43 UTC 2009 State-Changed-Why: In HEAD, we have support for -znodelete in ld.so, and libthr is linked with the flag. I have no plans for MFC ATM. The right thing to do is to link the main binary with -lpthread anyway. http://www.freebsd.org/cgi/query-pr.cgi?pr=135477