From owner-freebsd-current Fri Jun 1 10:58:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 2ACDC37B424; Fri, 1 Jun 2001 10:58:32 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.21.Dial1.SanJose1.Level3.net [209.245.138.21]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA19760; Fri, 1 Jun 2001 13:58:24 -0400 (EDT) Message-ID: <3B17D7DB.9469F2A2@mindspring.com> Date: Fri, 01 Jun 2001 10:58:51 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bmah@FreeBSD.ORG Cc: freebsd-current@FreeBSD.ORG Subject: Re: freelist corruption: more info References: <200105301637.f4UGbor75863@bmah-freebsd-0.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Bruce A. Mah" wrote: > > Trying to fix some make release problems, I've kept running into the > same freelist corruption problems that kris and dougb experienced > earlier this week. Main difference is that I notice when the box > (-CURRENT from 29 May, GENERIC kernel, UP) crashes. :-p > > Not being a -CURRENT guru, I haven't decided if I'm going to try Tor > Egge's patch or just slug it out to try to finish fixing make release > (which is my main goal at this point). > > Just as an FYI, here's the tombstone and a stack trace in case it's > useful to anyone. FWIW, for me, these have _always_ (well, except for the vnode reclaimer bug, but the vnode reclaimer is still a stupid idea 5 years later) been reference count rollover for things which free on 1->0 counts. My recommendation is to look for a structure in the kernel which is exactly 52 bytes long. A somewhate more arcane way of doing this is to cause the invariant that bitches about this in the allocator to panic the system (I can't tell if the "Data modified" message is a result of this having gone in or not -- I suggested it a while back, after I found the credentials reference count overflow). Really, all reference counted objects need to be handled by the same code -- macros, if we are to be able to do an INVARIANTS instrumentation of all 0->1 and ->0 transitions. This one looks like a "pagedep" reference overflow, rather than free-without-reference, problem, which is what you'd naievely think it was. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message