From owner-freebsd-current@FreeBSD.ORG Sat Feb 18 17:05:42 2006 Return-Path: X-Original-To: freebsd-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 198DF16A420 for ; Sat, 18 Feb 2006 17:05:42 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 4760F43D46 for ; Sat, 18 Feb 2006 17:05:41 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 91656 invoked by uid 399); 18 Feb 2006 17:05:37 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 18 Feb 2006 17:05:37 -0000 Message-ID: <43F753DE.6080806@FreeBSD.org> Date: Sat, 18 Feb 2006 09:05:34 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Jason Evans References: <1140187193.731.47.camel@spirit> <20060217181842.GA21033@odin.ac.hmc.edu> <43F65A70.7080608@FreeBSD.org> <20060217234118.GA22643@odin.ac.hmc.edu> <43F67121.5080809@FreeBSD.org> <43F682F2.1020804@FreeBSD.org> <43F68611.7080602@FreeBSD.org> In-Reply-To: <43F68611.7080602@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: New RCorder: abi loaded too late 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: Sat, 18 Feb 2006 17:05:42 -0000 Jason Evans wrote: > Doug Barton wrote: >> PS to jasone, the trace on the core file shows that the error in >> rcorder is >> at line 761 of rcorder.c (which was recently patched to fix a >> different kind >> of core dumping problem). I'd be glad to provide you or the list with >> more >> details if there is interest. > > Chances are good that the crash is due to a double free. If you have > trouble tracking this down, you can try reducing the size of the delay > cache (MALLOC_OPTIONS='cccccccc' will reduce the delay cache to one > item), which may cause a different failure mode that is easier to > interpret. That actually caused it not to fail, which arguably is more difficult to interpret. :) I tried backing off the number of c's, but it didn't dump core until I got all the way down to zero again, then I got a core with the same backtrace as before. FYI, Doug -- This .signature sanitized for your protection