From owner-freebsd-current@freebsd.org Tue May 29 14:24:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46B2AFBE462 for ; Tue, 29 May 2018 14:24:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6C776D784; Tue, 29 May 2018 14:24:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-25-190.dyn.iinet.net.au [115.166.25.190]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w4TEOA5k068898 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 May 2018 07:24:13 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: head@r334204, Bad link elm in callout_process() To: Andriy Gapon , Hans Petter Selasky , FreeBSD Current References: <84341ca3-90a5-97ef-8eee-dc1bbb07503c@selasky.org> <0df613ac-70aa-f793-1b7b-7a5e097fef28@FreeBSD.org> From: Julian Elischer Message-ID: Date: Tue, 29 May 2018 22:24:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0df613ac-70aa-f793-1b7b-7a5e097fef28@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 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: Tue, 29 May 2018 14:24:16 -0000 On 29/5/18 9:53 pm, Andriy Gapon wrote: > On 29/05/2018 14:53, Hans Petter Selasky wrote: >> On 05/29/18 13:20, Andriy Gapon wrote: >>> (kgdb) p *$4.lh_first->c_links.le.le_next >>> $6 = { >>>    c_links = { >>>      le = { >>>        le_next = 0x0, >>>        le_prev = 0xfffffe0003999f98 >> Where does the le_prev point? >> >> Typically happens when callouts are not properly drained before freeing memory. > Yeah, this could have been a pilot error. > I added some debugging code and that code could do callout_init + callout_reset > on an active or pending callout. I am not seeing the problem without the > debugging code. > Sorry for the noise! did you add code to that machine?? (bob.$work) >