From owner-freebsd-audit Mon Aug 12 8: 9:32 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0359D37B400; Mon, 12 Aug 2002 08:09:26 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B7843E65; Mon, 12 Aug 2002 08:09:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eGou-0000Cs-00; Mon, 12 Aug 2002 08:09:24 -0700 Message-ID: <3D57CF6D.2982CE8@mindspring.com> Date: Mon, 12 Aug 2002 08:08:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > You may also want to consider the use of a .init and .fini > > section for the code, to permit the creation of an initial > > lookup context chunk; this is kind of a tradeoff, but it will > > mean that a server will not have to do the recheck each time. > > The .fini section would aloow auto-cleanup. This may be a > > necessity for a long running program that uses a shared object > > to perform the thread creation and lookup (you could leak > > memory, otherwise). > > Could you please elaborate how exactly memory could be leaked in this > case, if the program does correctly shut down all its threads? Create PIC object foo.so. Link PIC object foo.so against libc.so. Call dlopen to load module foo.so into program "bob". Call function in foo.so from program "bob". Function in foo.so creates two threads, one for IPv4 lookup, another for IPv6 lookup to cause lookups to proceed concurrently. Lookup completes. Unload module foo.so. -> leak memory in libc.so image The assumption (which is potentially wrong) is that the program will correctly shut down all its threads, when in fact it was a module not under the programs control that created and used the threads. The leak depends on: 1) A pool of worker threads being created and left around or the purpose of simultaneous resolution 2) The parent shutting down the module without explicitly dealing with the threads (basically, code which would need to live in ".fini" of the foo.so, and could not be automatically triggered on unload of foo.so any other way). I think that parallel IPv6/IPv4 resolution presented as a single serial interface is a high probability implementation with the support for threaded access to the resolver, particularly with the Mozilla code acting the way it does. > I also would like to hear from you whether or not you think that we > need all those gethostbyXXX_r(3) functions. No. I don't think any of the _r functions are needed, so long as the results are not cached by pointer instead of a copy, before passing them from one thread to another. It's a risk on the clobber case of a call with a cached reference outstanding but not processed by another thread which is not an issue with the _r functions, which require that you pass the storage down. Of course, if you pass down per thread storage, you could have the same problem if you didn't copy rather than reference the results before passing to another thread by address. Given that, per thread allocations ("thread local storage") makes more sense than allocate/free fights between threads based on who's responsible for owning the memory after an inter-thread call. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message