From owner-freebsd-current@FreeBSD.ORG Tue Feb 7 19:14:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92B3F16A429 for ; Tue, 7 Feb 2006 19:14:23 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F6D43D48 for ; Tue, 7 Feb 2006 19:14:22 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k17JE8pr051077; Tue, 7 Feb 2006 11:14:08 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k17JE8Rr051076; Tue, 7 Feb 2006 11:14:08 -0800 (PST) (envelope-from sgk) Date: Tue, 7 Feb 2006 11:14:08 -0800 From: Steve Kargl To: Yar Tikhiy Message-ID: <20060207191408.GA50909@troutmask.apl.washington.edu> References: <20060207183152.GA50629@troutmask.apl.washington.edu> <20060207190121.GF19674@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207190121.GF19674@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: memguard monitoring of more than 1 memory_type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2006 19:14:23 -0000 On Tue, Feb 07, 2006 at 10:01:21PM +0300, Yar Tikhiy wrote: > On Tue, Feb 07, 2006 at 10:31:52AM -0800, Steve Kargl wrote: > > Can memguard monitor the usage of more that one memory_type? > > From the memguard(9) manpage: > > Currently, MemGuard can only take over malloc(), realloc() and free() for > a particular malloc type. Thanks for pointing out the obvious. I've read that manpage several times and somehow missed the word "particular". It's unfortunate that it can't monitor more than one type of memory allocation because the new pts code has either uncovered a latent bug in devfs or the pts patch is stomping on memory. -- Steve