From owner-freebsd-current@FreeBSD.ORG Thu Jun 26 03:51:59 2003 Return-Path: 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 BECF337B401; Thu, 26 Jun 2003 03:51:59 -0700 (PDT) Received: from cicero1.cybercity.dk (cicero1.cybercity.dk [212.242.40.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08EFF43F75; Thu, 26 Jun 2003 03:51:59 -0700 (PDT) (envelope-from db@traceroute.dk) Received: from user1.cybercity.dk (fxp0.user1.ip.cybercity.dk [212.242.41.34]) by cicero1.cybercity.dk (Postfix) with ESMTP id ED44C5C4A75; Thu, 26 Jun 2003 12:51:56 +0200 (CEST) Received: from main (port132.ds1-arsy.adsl.cybercity.dk [212.242.239.73]) by user1.cybercity.dk (Postfix) with SMTP id DBC1968AFF; Thu, 26 Jun 2003 12:51:52 +0200 (CEST) Date: Thu, 26 Jun 2003 12:59:36 +0200 From: Socketd To: Robert Watson , current@freebsd.org Message-Id: <20030626125936.76c8d6cd.db@traceroute.dk> In-Reply-To: References: <20030625191652.289ba4db.db@traceroute.dk> X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 5.1-Release freezes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 26 Jun 2003 10:52:00 -0000 On Wed, 25 Jun 2003 16:44:56 -0400 (EDT) Robert Watson wrote: > The code most likely to cause a memory leak in the MAC Framework is > the label management code, since that's the only code that really does > much in the way of memory allocaiton. Try compiling options MAC_DEBUG > into your kernel, which causes the MAC Framework to track the number > of labels it has allocated/free'd in a series of variables: > > static unsigned int nmacmbufs, nmaccreds, nmacifnets, nmacbpfdescs, > nmacsockets, nmacmounts, nmactemp, nmacvnodes, nmacdevfsdirents, > nmacipqs, nmacpipes, nmacprocs; > > You can inspect them using a series of sysctls in the > security.mac.debug tree; I'd be interested to see how those values > change as you approach the hang. Hmm, this is strange. I build the same kernel with: makeoptions DEBUG=-g options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options MAC options MAC_DEBUG Now it doesn't hang and there is nothing in the logs. Btw here is some info: security.mac.debug.label_fallback: 0 security.mac.debug.counters.mbufs: 0 security.mac.debug.counters.creds: 17 security.mac.debug.counters.ifnets: 3 security.mac.debug.counters.ipqs: 0 security.mac.debug.counters.bpfdescs: 0 security.mac.debug.counters.sockets: 7 security.mac.debug.counters.pipes: 2 security.mac.debug.counters.procs: 63 security.mac.debug.counters.mounts: 6 security.mac.debug.counters.temp: 0 security.mac.debug.counters.vnodes: 429 security.mac.debug.counters.devfsdirents: 96 Again I am not running anything but the base system and ssh. br socketd