Typical malloc-related application bugs
Jason Evans
jasone at FreeBSD.org
Thu Jan 19 23:40:22 PST 2006
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
More information about the freebsd-current
mailing list