From owner-freebsd-threads@FreeBSD.ORG Mon Oct 2 11:08:41 2006 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4191216A52F for ; Mon, 2 Oct 2006 11:08:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97C0F43D58 for ; Mon, 2 Oct 2006 11:08:40 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k92B8elZ001653 for ; Mon, 2 Oct 2006 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k92B8dak001649 for freebsd-threads@FreeBSD.org; Mon, 2 Oct 2006 11:08:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Oct 2006 11:08:39 GMT Message-Id: <200610021108.k92B8dak001649@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 02 Oct 2006 11:08:41 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu 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 o kern/38549 threads the procces compiled whith pthread stopped in pthread_ 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 s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72353 threads Assertion fails in /usr/src/lib/libpthread/sys/lock.c, o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella 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 o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/101355 threads threaded application spents too much time in _umtx_op 29 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim 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/74180 threads KSE problem. Applications those riched maximum possibl 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/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 10 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Oct 4 14:00:53 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CB7B16A4DA for ; Wed, 4 Oct 2006 14:00:53 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 167F643D5A for ; Wed, 4 Oct 2006 14:00:52 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k94E0pTd092065 for ; Wed, 4 Oct 2006 14:00:51 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k94E0pIc092064; Wed, 4 Oct 2006 14:00:51 GMT (envelope-from gnats) Resent-Date: Wed, 4 Oct 2006 14:00:51 GMT Resent-Message-Id: <200610041400.k94E0pIc092064@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, KUROSAWA@FreeBSD.org, Takahiro Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C8C316A403 for ; Wed, 4 Oct 2006 13:56:34 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2351643D7E for ; Wed, 4 Oct 2006 13:56:24 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k94DuOxm097239 for ; Wed, 4 Oct 2006 13:56:24 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k94DuOmj097237; Wed, 4 Oct 2006 13:56:24 GMT (envelope-from nobody) Message-Id: <200610041356.k94DuOmj097237@www.freebsd.org> Date: Wed, 4 Oct 2006 13:56:24 GMT From: KUROSAWA@FreeBSD.org, Takahiro To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes 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, 04 Oct 2006 14:00:53 -0000 >Number: 103975 >Category: threads >Synopsis: Implicit loading/unloading of libpthread.so may crash user processes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 04 14:00:50 GMT 2006 >Closed-Date: >Last-Modified: >Originator: KUROSAWA, Takahiro >Release: 6.2-PRERELEASE >Organization: >Environment: FreeBSD cube.nodomain.noroot 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #13: Fri Sep 29 14:34:05 JST 2006 kurosawa@cube.nodomain.noroot:/usr/obj/usr/src/sys/CUBE i386 >Description: A program (described as ProgA below) gets SIGSEGV if following conditions are met: - ProgA dlopen()s and dlclose()s a shared object (ShobjB) - ProgA doesn't link libpthread.so - ShbjB dynamically links libpthread.so (libpthread.so will be loaded when ProgA dlopen()s ShobjB) - ProgA calls functions like gethostbyname() that uses __thr_jtable (in src/lib/libc/gen/_pthread_stubs.c) after unloading ShobjB. The problem is that function pointers in __thr_jtable still point to functions in libpthread.so after libpthread.so is unloaded from ProgA's memory space. To fix the problem, a function that has __attribute__((destructor)) in libpthread should probably be implemented in order to recover the initial state before unloading. >How-To-Repeat: The problem occurs on the web server built with following ports when the httpd receives SIGHUP that is sent by newsyslog: - www/apache20 - lang/php4 - databases/php4-pgsql - databases/postgresql81-{client,server} with the option WITH_THREADSAFE=true Or extract the following archive then run "make test." The 3rd call of test() in pjt-replace.c causes SIGSEGV. begin 644 pjt.tar.gz M'XL(`#J[(T4``^V4WV_3,!#'^QK_%:?02>GH#[=-6JFC$Z,;?2DO6WD`(2'7 M<99L7A+%SA!"_._8257:CL%3-P'W>;GX_#W?Q9=+?J,;AX92.@X",+8_#OK6 M4CKP:[L&^C3HT_$P\`,*M#\(1N,&!`>OS%`JS0I3RFU99(I]88_IC"R*?G/. M^CTV]B\AO]&]=^Q61(D4A\IA[F/D^X_WWQ\,]_KO#VG0`'JH@K;YS_M_?O'F M_=QQIM"Y)K.WB[/YE>.\G$+3JS9:9'EV.;]87EF%^52Z*K.F4XA<,BX(85). M?KFAA=(3,-O$Z?9V=K86D^V8;D:;M3;)H9-!\_6>AM39ZE"5=?G#*!6S M0H1;T58&'9GKN!`LK$NPO@EQ.-/0"\5]+RVEA%,309Z[)4^*G?_M"^8'R/&G M^0]&_M[\!X,!SO^3\"))N2Q#`:]"&?&T&Y^2GRZEPR3;=:5"AROK(N9"=,+A M/DO":MH];L8.CD.A>(M\(X[21+\\^+LXP>KJ6-9 MI$6QUK9AMG+WX8LQ$1IWX%H+;DY^XY@B`(@B`(@B`(@B`(@B`( 2@B`(@B`(\N_Q`XCZB,H`*``` ` end >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Thu Oct 5 13:14:54 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB87916A412; Thu, 5 Oct 2006 13:14:54 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB0F243D49; Thu, 5 Oct 2006 13:14:53 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k95DEnOI043546; Thu, 5 Oct 2006 09:14:49 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 5 Oct 2006 09:06:20 -0400 User-Agent: KMail/1.9.1 References: <200610041356.k94DuOmj097237@www.freebsd.org> In-Reply-To: <200610041356.k94DuOmj097237@www.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610050906.21304.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Thu, 05 Oct 2006 09:14:49 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1997/Wed Oct 4 11:20:43 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-104.4 required=4.2 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Takahiro , freebsd-gnats-submit@freebsd.org, KUROSAWA@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes 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, 05 Oct 2006 13:14:54 -0000 On Wednesday 04 October 2006 09:56, KUROSAWA@freebsd.org, Takahiro wrote: > > >Number: 103975 > >Category: threads > >Synopsis: Implicit loading/unloading of libpthread.so may crash user processes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-threads > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Oct 04 14:00:50 GMT 2006 > >Closed-Date: > >Last-Modified: > >Originator: KUROSAWA, Takahiro > >Release: 6.2-PRERELEASE > >Organization: > >Environment: > FreeBSD cube.nodomain.noroot 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #13: Fri Sep 29 14:34:05 JST 2006 kurosawa@cube.nodomain.noroot:/usr/obj/usr/src/sys/CUBE i386 > > >Description: > A program (described as ProgA below) gets SIGSEGV if following conditions > are met: > - ProgA dlopen()s and dlclose()s a shared object (ShobjB) > - ProgA doesn't link libpthread.so > - ShbjB dynamically links libpthread.so > (libpthread.so will be loaded when ProgA dlopen()s ShobjB) > - ProgA calls functions like gethostbyname() that uses __thr_jtable > (in src/lib/libc/gen/_pthread_stubs.c) after unloading ShobjB. > > The problem is that function pointers in __thr_jtable still point to functions > in libpthread.so after libpthread.so is unloaded from ProgA's memory space. Actually, I wonder if it should be allowed to unload at all. On 4.x at work we ran into an issue with the linuxthreads library loading, setting _is_threaded, then unloading with a malloc() occurring during the destructors resolving a _spinlock() weak symbol, then after the libraries were completely unloaded, the next malloc() blew up when _spinlock() pointed off into space. Hmm, this specific condition is handled I think since __isthreaded in 6.x libpthread isn't set until you do pthread_create() which at that point means a symbol is resolved, and the library won't be unloaded (I think). Hmm, maybe not since that doesn't guarantee that libc depends on libpthread (that is what keeps it from being unloaded IIRC). So, maybe when the library sets __isthreaded it should call one of the libc functions (like malloc) to force one of the weak symbols to be resolved so it isn't unloaded. > To fix the problem, a function that has __attribute__((destructor)) > in libpthread should probably be implemented in order to recover > the initial state before unloading. I'm not sure you can recover the state actually, hence why I think maybe we should make it so that libpthread doesn't unload once it has been loaded. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Oct 5 13:20:29 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4A2E16A407 for ; Thu, 5 Oct 2006 13:20:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BD5143D46 for ; Thu, 5 Oct 2006 13:20:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k95DKSKi050904 for ; Thu, 5 Oct 2006 13:20:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k95DKSDL050902; Thu, 5 Oct 2006 13:20:28 GMT (envelope-from gnats) Date: Thu, 5 Oct 2006 13:20:28 GMT Message-Id: <200610051320.k95DKSDL050902@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: John Baldwin Cc: Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2006 13:20:29 -0000 The following reply was made to PR threads/103975; it has been noted by GNATS. From: John Baldwin To: freebsd-threads@freebsd.org Cc: KUROSAWA@freebsd.org, Takahiro , freebsd-gnats-submit@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes Date: Thu, 5 Oct 2006 09:06:20 -0400 On Wednesday 04 October 2006 09:56, KUROSAWA@freebsd.org, Takahiro wrote: > > >Number: 103975 > >Category: threads > >Synopsis: Implicit loading/unloading of libpthread.so may crash user processes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-threads > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Oct 04 14:00:50 GMT 2006 > >Closed-Date: > >Last-Modified: > >Originator: KUROSAWA, Takahiro > >Release: 6.2-PRERELEASE > >Organization: > >Environment: > FreeBSD cube.nodomain.noroot 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #13: Fri Sep 29 14:34:05 JST 2006 kurosawa@cube.nodomain.noroot:/usr/obj/usr/src/sys/CUBE i386 > > >Description: > A program (described as ProgA below) gets SIGSEGV if following conditions > are met: > - ProgA dlopen()s and dlclose()s a shared object (ShobjB) > - ProgA doesn't link libpthread.so > - ShbjB dynamically links libpthread.so > (libpthread.so will be loaded when ProgA dlopen()s ShobjB) > - ProgA calls functions like gethostbyname() that uses __thr_jtable > (in src/lib/libc/gen/_pthread_stubs.c) after unloading ShobjB. > > The problem is that function pointers in __thr_jtable still point to functions > in libpthread.so after libpthread.so is unloaded from ProgA's memory space. Actually, I wonder if it should be allowed to unload at all. On 4.x at work we ran into an issue with the linuxthreads library loading, setting _is_threaded, then unloading with a malloc() occurring during the destructors resolving a _spinlock() weak symbol, then after the libraries were completely unloaded, the next malloc() blew up when _spinlock() pointed off into space. Hmm, this specific condition is handled I think since __isthreaded in 6.x libpthread isn't set until you do pthread_create() which at that point means a symbol is resolved, and the library won't be unloaded (I think). Hmm, maybe not since that doesn't guarantee that libc depends on libpthread (that is what keeps it from being unloaded IIRC). So, maybe when the library sets __isthreaded it should call one of the libc functions (like malloc) to force one of the weak symbols to be resolved so it isn't unloaded. > To fix the problem, a function that has __attribute__((destructor)) > in libpthread should probably be implemented in order to recover > the initial state before unloading. I'm not sure you can recover the state actually, hence why I think maybe we should make it so that libpthread doesn't unload once it has been loaded. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Oct 5 23:48:03 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F0A616A407 for ; Thu, 5 Oct 2006 23:48:03 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4640343D45 for ; Thu, 5 Oct 2006 23:48:02 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so876966pye for ; Thu, 05 Oct 2006 16:48:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=st4dEZ31RunMFs6q9CUw/K1FSBuLTIbcSl6QDgZ1mCxL32o5Wb9tlXTPrgFyHZXZSj5/kBpF5kdnXIYjGcGKMTNTTyQKkXxNQX4B0SJdPDkW32MlxitgqO3dFRI2/HUqFVvV/2u9rbI91H+Eol/RmHmXIWwLgBoPCrHzvH/wIKs= Received: by 10.65.154.4 with SMTP id g4mr3245764qbo; Thu, 05 Oct 2006 16:48:01 -0700 (PDT) Received: from kan.dnsalias.net ( [24.63.93.195]) by mx.google.com with ESMTP id e18sm1692902qbe.2006.10.05.16.48.01; Thu, 05 Oct 2006 16:48:01 -0700 (PDT) Date: Thu, 5 Oct 2006 19:47:56 -0400 From: Alexander Kabaev To: John Baldwin Message-ID: <20061005194756.07580108@kan.dnsalias.net> In-Reply-To: <200610050906.21304.john@baldwin.cx> References: <200610041356.k94DuOmj097237@www.freebsd.org> <200610050906.21304.john@baldwin.cx> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_olRQb9w73LRMGWxv5Pd0njU; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Takahiro , freebsd-gnats-submit@freebsd.org, KUROSAWA@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes 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, 05 Oct 2006 23:48:03 -0000 --Sig_olRQb9w73LRMGWxv5Pd0njU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 5 Oct 2006 09:06:20 -0400 John Baldwin wrote: >=20 > Actually, I wonder if it should be allowed to unload at all. On 4.x > at work we ran into an issue with the linuxthreads library loading, > setting _is_threaded, then unloading with a malloc() occurring during > the destructors resolving a _spinlock() weak symbol, then after the > libraries were completely unloaded, the next malloc() blew up when > _spinlock() pointed off into space. Hmm, this specific condition is > handled I think since __isthreaded in 6.x libpthread isn't set until > you do pthread_create() which at that point means a symbol is > resolved, and the library won't be unloaded (I think). Hmm, maybe > not since that doesn't guarantee that libc depends on libpthread > (that is what keeps it from being unloaded IIRC). So, maybe when the > library sets __isthreaded it should call one of the libc functions > (like malloc) to force one of the weak symbols to be resolved so it > isn't unloaded. >=20 > > To fix the problem, a function that has __attribute__((destructor)) > > in libpthread should probably be implemented in order to recover > > the initial state before unloading. >=20 > I'm not sure you can recover the state actually, hence why I think > maybe we should make it so that libpthread doesn't unload once it has > been loaded. >=20 > --=20 > John Baldwin Linux does not allow pthread library to be unloaded presumably because of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST Infortunately, rtld does not implement NODELETE and INITFIRST. Both are addressed in my patch that I am yet to commit. --=20 Alexander Kabaev --Sig_olRQb9w73LRMGWxv5Pd0njU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFJZmvQ6z1jMm+XZYRAkaKAJ9/bV9FU6UgIVbE7QZAhBLKD7rg5ACeMjGr 1DVtUSKdDtw5N2PFrbduuwc= =+av7 -----END PGP SIGNATURE----- --Sig_olRQb9w73LRMGWxv5Pd0njU-- From owner-freebsd-threads@FreeBSD.ORG Thu Oct 5 23:50:28 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD03B16A412 for ; Thu, 5 Oct 2006 23:50:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 617FE43D49 for ; Thu, 5 Oct 2006 23:50:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k95NoRVA021256 for ; Thu, 5 Oct 2006 23:50:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k95NoRVM021255; Thu, 5 Oct 2006 23:50:27 GMT (envelope-from gnats) Date: Thu, 5 Oct 2006 23:50:27 GMT Message-Id: <200610052350.k95NoRVM021255@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Alexander Kabaev Cc: Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes 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: Thu, 05 Oct 2006 23:50:28 -0000 The following reply was made to PR threads/103975; it has been noted by GNATS. From: Alexander Kabaev To: John Baldwin Cc: freebsd-threads@freebsd.org, Takahiro , freebsd-gnats-submit@freebsd.org, KUROSAWA@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes Date: Thu, 5 Oct 2006 19:47:56 -0400 --Sig_olRQb9w73LRMGWxv5Pd0njU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 5 Oct 2006 09:06:20 -0400 John Baldwin wrote: >=20 > Actually, I wonder if it should be allowed to unload at all. On 4.x > at work we ran into an issue with the linuxthreads library loading, > setting _is_threaded, then unloading with a malloc() occurring during > the destructors resolving a _spinlock() weak symbol, then after the > libraries were completely unloaded, the next malloc() blew up when > _spinlock() pointed off into space. Hmm, this specific condition is > handled I think since __isthreaded in 6.x libpthread isn't set until > you do pthread_create() which at that point means a symbol is > resolved, and the library won't be unloaded (I think). Hmm, maybe > not since that doesn't guarantee that libc depends on libpthread > (that is what keeps it from being unloaded IIRC). So, maybe when the > library sets __isthreaded it should call one of the libc functions > (like malloc) to force one of the weak symbols to be resolved so it > isn't unloaded. >=20 > > To fix the problem, a function that has __attribute__((destructor)) > > in libpthread should probably be implemented in order to recover > > the initial state before unloading. >=20 > I'm not sure you can recover the state actually, hence why I think > maybe we should make it so that libpthread doesn't unload once it has > been loaded. >=20 > --=20 > John Baldwin Linux does not allow pthread library to be unloaded presumably because of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST Infortunately, rtld does not implement NODELETE and INITFIRST. Both are addressed in my patch that I am yet to commit. --=20 Alexander Kabaev --Sig_olRQb9w73LRMGWxv5Pd0njU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFJZmvQ6z1jMm+XZYRAkaKAJ9/bV9FU6UgIVbE7QZAhBLKD7rg5ACeMjGr 1DVtUSKdDtw5N2PFrbduuwc= =+av7 -----END PGP SIGNATURE----- --Sig_olRQb9w73LRMGWxv5Pd0njU-- From owner-freebsd-threads@FreeBSD.ORG Fri Oct 6 08:49:51 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F90B16A407 for ; Fri, 6 Oct 2006 08:49:51 +0000 (UTC) (envelope-from takahiro.kurosawa@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3189D43D53 for ; Fri, 6 Oct 2006 08:49:49 +0000 (GMT) (envelope-from takahiro.kurosawa@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1153575nfc for ; Fri, 06 Oct 2006 01:49:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=exefOSKSYh1apI3Gj9eEX0dZGTKsUXR7h/cITkvJI9qKZBQrW59Tsc8cu1+pmXpiez8MjUsJgLMXSU37Ojn5FkJAMQqhmIBU4yqetfRCqH8fJWAKdPv5Fl59r8yZe2GTUOqgFkQ+ZoCaEzuzEyHa3SyJe7Rsvfvkc7V4e1vzWtE= Received: by 10.82.142.9 with SMTP id p9mr163106bud; Fri, 06 Oct 2006 01:49:48 -0700 (PDT) Received: by 10.82.126.17 with HTTP; Fri, 6 Oct 2006 01:49:48 -0700 (PDT) Message-ID: Date: Fri, 6 Oct 2006 17:49:48 +0900 From: "Takahiro Kurosawa" To: "Alexander Kabaev" In-Reply-To: <20061005194756.07580108@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610041356.k94DuOmj097237@www.freebsd.org> <200610050906.21304.john@baldwin.cx> <20061005194756.07580108@kan.dnsalias.net> Cc: John Baldwin , freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes 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, 06 Oct 2006 08:49:51 -0000 Alexander Kabaev wrote: > On Thu, 5 Oct 2006 09:06:20 -0400 > John Baldwin wrote: > > > > To fix the problem, a function that has __attribute__((destructor)) > > > in libpthread should probably be implemented in order to recover > > > the initial state before unloading. > > > > I'm not sure you can recover the state actually, hence why I think > > maybe we should make it so that libpthread doesn't unload once it has > > been loaded. I understand that it's way easier to prohibit unloading of libpthread than to change the code safely unloadable. Thanks for your explanation, John! > Linux does not allow pthread library to be unloaded presumably because > of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: > > 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST > > Infortunately, rtld does not implement NODELETE and INITFIRST. Both are > addressed in my patch that I am yet to commit. I'm looking forward to the commit of your patch into the CVS repository :-) Maybe the following line should be added to src/lib/libpthread/Makefile when rtld supports the NODELETE flag? : LDFLAGS+=-Wl,-znodelete Thanks, -- KUROSAWA, Takahiro From owner-freebsd-threads@FreeBSD.ORG Fri Oct 6 08:50:28 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E72DD16A415 for ; Fri, 6 Oct 2006 08:50:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74AFB43D5C for ; Fri, 6 Oct 2006 08:50:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k968oQMO084990 for ; Fri, 6 Oct 2006 08:50:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k968oQwM084989; Fri, 6 Oct 2006 08:50:26 GMT (envelope-from gnats) Date: Fri, 6 Oct 2006 08:50:26 GMT Message-Id: <200610060850.k968oQwM084989@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: "Takahiro Kurosawa" Cc: Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Takahiro Kurosawa List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 08:50:29 -0000 The following reply was made to PR threads/103975; it has been noted by GNATS. From: "Takahiro Kurosawa" To: "Alexander Kabaev" Cc: "John Baldwin" , freebsd-threads@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes Date: Fri, 6 Oct 2006 17:49:48 +0900 Alexander Kabaev wrote: > On Thu, 5 Oct 2006 09:06:20 -0400 > John Baldwin wrote: > > > > To fix the problem, a function that has __attribute__((destructor)) > > > in libpthread should probably be implemented in order to recover > > > the initial state before unloading. > > > > I'm not sure you can recover the state actually, hence why I think > > maybe we should make it so that libpthread doesn't unload once it has > > been loaded. I understand that it's way easier to prohibit unloading of libpthread than to change the code safely unloadable. Thanks for your explanation, John! > Linux does not allow pthread library to be unloaded presumably because > of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: > > 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST > > Infortunately, rtld does not implement NODELETE and INITFIRST. Both are > addressed in my patch that I am yet to commit. I'm looking forward to the commit of your patch into the CVS repository :-) Maybe the following line should be added to src/lib/libpthread/Makefile when rtld supports the NODELETE flag? : LDFLAGS+=-Wl,-znodelete Thanks, -- KUROSAWA, Takahiro From owner-freebsd-threads@FreeBSD.ORG Fri Oct 6 12:42:49 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54F9516A403; Fri, 6 Oct 2006 12:42:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F37A643DA1; Fri, 6 Oct 2006 12:42:23 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k96CgJsR029485; Fri, 6 Oct 2006 08:42:19 -0400 (EDT) Date: Fri, 6 Oct 2006 08:42:19 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Takahiro Kurosawa In-Reply-To: Message-ID: References: <200610041356.k94DuOmj097237@www.freebsd.org> <200610050906.21304.john@baldwin.cx> <20061005194756.07580108@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 06 Oct 2006 08:42:19 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: John Baldwin , freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 12:42:49 -0000 On Fri, 6 Oct 2006, Takahiro Kurosawa wrote: > Alexander Kabaev wrote: >> On Thu, 5 Oct 2006 09:06:20 -0400 >> John Baldwin wrote: >> >> > > To fix the problem, a function that has __attribute__((destructor)) >> > > in libpthread should probably be implemented in order to recover >> > > the initial state before unloading. >> > >> > I'm not sure you can recover the state actually, hence why I think >> > maybe we should make it so that libpthread doesn't unload once it has >> > been loaded. > > I understand that it's way easier to prohibit unloading of libpthread > than to change the code safely unloadable. > Thanks for your explanation, John! > >> Linux does not allow pthread library to be unloaded presumably because >> of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: >> >> 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST >> >> Infortunately, rtld does not implement NODELETE and INITFIRST. Both are >> addressed in my patch that I am yet to commit. > > I'm looking forward to the commit of your patch into the CVS repository :-) > Maybe the following line should be added to src/lib/libpthread/Makefile > when rtld supports the NODELETE flag? : > LDFLAGS+=-Wl,-znodelete If that's the knob, then I'd agree. You also want to make the same change to libthr. -- Dan From owner-freebsd-threads@FreeBSD.ORG Fri Oct 6 12:50:21 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AE1816A403 for ; Fri, 6 Oct 2006 12:50:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C27C243D45 for ; Fri, 6 Oct 2006 12:50:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k96CoKxZ002709 for ; Fri, 6 Oct 2006 12:50:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k96CoK2R002708; Fri, 6 Oct 2006 12:50:20 GMT (envelope-from gnats) Date: Fri, 6 Oct 2006 12:50:20 GMT Message-Id: <200610061250.k96CoK2R002708@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 12:50:21 -0000 The following reply was made to PR threads/103975; it has been noted by GNATS. From: Daniel Eischen To: Takahiro Kurosawa Cc: Alexander Kabaev , John Baldwin , freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/103975: Implicit loading/unloading of libpthread.so may crash user processes Date: Fri, 6 Oct 2006 08:42:19 -0400 (EDT) On Fri, 6 Oct 2006, Takahiro Kurosawa wrote: > Alexander Kabaev wrote: >> On Thu, 5 Oct 2006 09:06:20 -0400 >> John Baldwin wrote: >> >> > > To fix the problem, a function that has __attribute__((destructor)) >> > > in libpthread should probably be implemented in order to recover >> > > the initial state before unloading. >> > >> > I'm not sure you can recover the state actually, hence why I think >> > maybe we should make it so that libpthread doesn't unload once it has >> > been loaded. > > I understand that it's way easier to prohibit unloading of libpthread > than to change the code safely unloadable. > Thanks for your explanation, John! > >> Linux does not allow pthread library to be unloaded presumably because >> of reasons like this. From readelf -a /compat/linux/lib/libpthread.so.0: >> >> 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST >> >> Infortunately, rtld does not implement NODELETE and INITFIRST. Both are >> addressed in my patch that I am yet to commit. > > I'm looking forward to the commit of your patch into the CVS repository :-) > Maybe the following line should be added to src/lib/libpthread/Makefile > when rtld supports the NODELETE flag? : > LDFLAGS+=-Wl,-znodelete If that's the knob, then I'd agree. You also want to make the same change to libthr. -- Dan