From owner-freebsd-bugs  Mon May 12 20:40:08 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id UAA26129
          for bugs-outgoing; Mon, 12 May 1997 20:40:08 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id UAA26087;
          Mon, 12 May 1997 20:40:04 -0700 (PDT)
Date: Mon, 12 May 1997 20:40:04 -0700 (PDT)
Message-Id: <199705130340.UAA26087@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: David Greenman <dg@root.com>
Subject: Re: kern/3583: 'sysctl kern' dumps core when displaying clockrate 
Reply-To: David Greenman <dg@root.com>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/3583; it has been noted by GNATS.

From: David Greenman <dg@root.com>
To: randy@zyzzyva.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, phk@FreeBSD.ORG
Subject: Re: kern/3583: 'sysctl kern' dumps core when displaying clockrate 
Date: Mon, 12 May 1997 20:30:16 -0700

 >	sysctl kern works fine within the first few minutes after a reboot.
 >	Soon, it begins dumping core when attempting to print/retreive 
 >	kern.clockrate. I've reported this in the past, but I cannot find it 
 >	in the gnats DB. It is possible that it was mistakenly closed when I 
 >	thought it had been fixed since it works right after rebooting.
 
 >! 	i = sysctl(oid, nlen, 0, &j, 0, 0);
 >! 	j += j; /* we want to be sure :-) */
 >! 
 >  	val = alloca(j);
 >  	len = j;
 >  	i = sysctl(oid, nlen, val, &len, 0, 0);
 >--- 341,347 ----
 >  
 >  	/* find an estimate of how much we need for this var */
 >  	j = 0;
 >! 	i = sysctl(oid, nlen, NULL, &j, 0, 0);
 >  	val = alloca(j);
 >  	len = j;
 
    The problem is caused by the proc structs being too large to fit on
 your stack - thus causing an rlimit violation. This is actually an
 architectural flaw in the sysctl mechanism since the information returned
 from reading the struct procs is actually later discarded. The code needs
 to be re-written to only retrieve sysctl variables that are actually needed.
 You can temporarily work around the problem by increasing your stack rlimit
 to something larger than 8MB.
 
 -DG
 
 David Greenman
 Core-team/Principal Architect, The FreeBSD Project