From owner-freebsd-current@FreeBSD.ORG Fri Jan 20 07:40:22 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 2B5CB16A41F; Fri, 20 Jan 2006 07:40:22 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C85D143D46; Fri, 20 Jan 2006 07:40:21 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id A8C515E48C0; Thu, 19 Jan 2006 23:40:21 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 201D55E48C0; Thu, 19 Jan 2006 23:40:21 -0800 (PST) In-Reply-To: <1137741767.75264.27.camel@shumai.marcuscom.com> References: <6BD97F93-5E85-4A5A-8751-DC0C0382B916@FreeBSD.org> <1137741767.75264.27.camel@shumai.marcuscom.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61EE2752-7328-4068-9888-7F7B5C918439@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Thu, 19 Jan 2006 23:40:21 -0800 To: Joe Marcus Clarke X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: Typical malloc-related application bugs 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: Fri, 20 Jan 2006 07:40:22 -0000 On Jan 19, 2006, at 11:22 PM, Joe Marcus Clarke wrote: > On Thu, 2006-01-19 at 23:10 -0800, Jason Evans wrote: >> 2) Out-of-bounds writes. Lots of programs have been found to write >> past the end of the space they allocate. At the moment, jemalloc's >> redzone code is enabled, so these errors are causing messages to >> stderr that look like: >> >> ifconfig: (malloc) Corrupted redzone 1 byte after 0xa000150 (size >> 18) (0x0) > > I'm seeing a lot of this when I run gnome-system-monitor. There > appears > to be a bug in libgtop, but I don't know how to make these messages > fatal in order to produce a backtrace I can use to narrow down > where the > problem lies. What can I do to isolate where in the code the redzone > corruption is occurring? If you have the 'A' flag set, then you should be getting coredumps, unless gnome-system-monitor masks the SIGABRT signal. If you can't get coredumps, then you could try running gnome-system-monitor in gdb, with a breakpoint set in the branch of malloc.c:redzone_check() that calls abort(). > Additionally, do you have any example code that produces this kind of > redzone corruption? Thanks. Here is a quick hack that I wrote when testing the redzone code: --- #include #include #define SIZE 25 int main(void) { char *p; int i; p = (char *)malloc(SIZE); for (i = 1; i <= 16; i++) { p[-i] = 0x42 - i; } for (i = 0; i < 16; i++) { p[SIZE + i] = 0x43 + i; } free(p); return 0; } --- Note that redzones are currently defined to be 16 bytes, but there may be more than 16 bytes of trailing redzone space, depending on (size % 16). Jason