Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jan 2006 23:40:21 -0800
From:      Jason Evans <jasone@FreeBSD.org>
To:        Joe Marcus Clarke <marcus@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Typical malloc-related application bugs
Message-ID:  <61EE2752-7328-4068-9888-7F7B5C918439@FreeBSD.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdio.h>
#include <stdlib.h>

#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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61EE2752-7328-4068-9888-7F7B5C918439>