From owner-freebsd-hackers Mon May 21 22: 1: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6CF7C37B422; Mon, 21 May 2001 22:01:07 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4M517P12040; Mon, 21 May 2001 22:01:07 -0700 (PDT) (envelope-from dillon) Date: Mon, 21 May 2001 22:01:07 -0700 (PDT) From: Matt Dillon Message-Id: <200105220501.f4M517P12040@earth.backplane.com> To: John Baldwin Cc: "Brian F. Feldman" , hackers@FreeBSD.org Subject: Re: RE: vmspace leak (+ tentative fix) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Ok, then why not let the current shmexit() stay in exit1() as a hack to help :free memory, but add in a check in vmspace_free() as well to catch any race :conditions that may fall through the cracks? As long as we clear the shm :pointer in struct vmspace when we free it then we won't be double free'ing, and :will always free it eventually. That is also a much simpler change. :) :Additionally, adding to the comment in exit1() clarifying that this is an :attempt to free resources as soon as possible and that the race condition is :known and that vmspace_free() is a catch-all might be nice as well. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ :PGP Key: http://www.baldwin.cx/~john/pgpkey.asc It's not really good programming practice. Someone might trip over it later on. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message