From owner-freebsd-current@FreeBSD.ORG Tue Mar 2 17:17:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD081106566B for ; Tue, 2 Mar 2010 17:17:05 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 900AB8FC1C for ; Tue, 2 Mar 2010 17:17:05 +0000 (UTC) Received: from [192.168.116.131] (out1-1601fw.corp.tfbnw.net [66.220.144.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 7FBE72845A; Tue, 2 Mar 2010 09:17:04 -0800 (PST) Message-ID: <4B8D4806.7090704@freebsd.org> Date: Tue, 02 Mar 2010 09:16:54 -0800 From: Jason Evans User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Atkinson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: malloc problems in -current malloc_usable_size() 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: Tue, 02 Mar 2010 17:17:05 -0000 Mark Atkinson wrote: > I updated my kernel/world yesterday and thunderbird 3.0.2 started core > dumping after I completed the upgrade. It continued to do so on > previously good operations after a full re-compile. > > I noticed that some jemalloc changes went in and was wondering if anyone > else was noticing SEGV problems in other apps with malloc_usable_size() > or ARENA problems in threaded apps? > > (gdb) bt > #0 0x28eacb14 in malloc_usable_size () from /lib/libc.so.7 > #1 0x28eadbaa in free () from /lib/libc.so.7 > #2 0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10 This failure (segfault due to accessing an unmapped region of memory) is more subtle than I would typically expect of a malloc bug. My approach to debugging this would be to turn on tracing (see MALLOC_OPTIONS=U docs) and see if the pointer passed to free() was valid (i.e. returned by malloc/calloc/realloc, but not yet freed). Jason