From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 09:24:04 2005 Return-Path: X-Original-To: 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 BCE2816A421 for ; Sun, 26 Jun 2005 09:24:04 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 29DB443D1D for ; Sun, 26 Jun 2005 09:24:04 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 74269 invoked from network); 26 Jun 2005 09:24:02 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 26 Jun 2005 09:24:02 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 26 Jun 2005 04:23:46 -0500 (CDT) From: Mike Silbersack To: Thierry Herbelot In-Reply-To: <200506261049.42303.thierry@herbelot.com> Message-ID: <20050626042202.W7093@odysseus.silby.com> References: <20050624212729.C537@odysseus.silby.com> <20050626012002.H935@odysseus.silby.com> <20050626064309.GA4700@nagual.pp.ru> <200506261049.42303.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Mbuf double-free guilty party detection patch 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: Sun, 26 Jun 2005 09:24:04 -0000 On Sun, 26 Jun 2005, Thierry Herbelot wrote: > still no good luck : after using the second patch, no panic, but the debug > messages seem incomplete : (last freed by: /0/) > > This memory last freed by: 0 > Memory modified after free 0xc15d5800(256) val=800 @ 0xc15d583c > This memory last freed by: 0 > Memory modified after free 0xc15d5800(256) val=0 @ 0xc15d5840 > This memory last freed by: 0 > Memory modified after free 0xc15d5800(256) val=3 @ 0xc15d5844 Well, since I store the address inside of the mbuf, if whatever reuses it zeros it out, we'll see zero. :( Once I have memguard modified, we'll see what we can learn. > the test case is : building the kernel while tar-ing the src tree over two > separate ssh session. > > TfH > > PS : what is puzzling is that I've got another machine running a more recent > -current, with no ill effects (but it uses an ed(4) I/F) It'll be interesting to learn the answer. :) Mike "Silby" Silbersack