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