From owner-cvs-src@FreeBSD.ORG Thu Feb 24 20:20:43 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D29816A4DB; Thu, 24 Feb 2005 20:20:43 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CAA443D31; Thu, 24 Feb 2005 20:20:19 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j1OKKI6d084391; Thu, 24 Feb 2005 14:20:18 -0600 (CST) (envelope-from dan) Date: Thu, 24 Feb 2005 14:20:18 -0600 From: Dan Nelson To: Mike Silbersack Message-ID: <20050224202018.GA60363@dan.emsphone.com> References: <20050224140327.V8585@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224140327.V8585@odysseus.silby.com> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Robert Watson cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 20:20:44 -0000 In the last episode (Feb 24), Mike Silbersack said: > FWIW, Dan Nelson had a similar double-free problem a while back, I sent > him some additional debugging code to see what might be going wrong, but > it must not have happened again, he didn't get back to me. > > Dan, any new news? Nope; that particular panic has not reappeared on my system since you sent me that extra M_ASSERTVALID call. Code knows when it's being watched. Probably unrelated, but I have not seen a TX underrun error since Jan 31, and I had been getting a couple every week before that. > Since he was using if_dc, that leads me to believe that the problem > is somewhere in the socket layer or in the IFQ. If Peter can > reproduce this problem, have him throw a M_ASSERTVALID() after the > IFQ_DRV_DEQUEUE, that might prevent the double-free earlier. -- Dan Nelson dnelson@allantgroup.com