Date: Fri, 20 Jan 2006 02:43:15 -0500 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Jason Evans <jasone@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Typical malloc-related application bugs Message-ID: <1137742995.75264.30.camel@shumai.marcuscom.com> In-Reply-To: <61EE2752-7328-4068-9888-7F7B5C918439@FreeBSD.org> References: <6BD97F93-5E85-4A5A-8751-DC0C0382B916@FreeBSD.org> <1137741767.75264.27.camel@shumai.marcuscom.com> <61EE2752-7328-4068-9888-7F7B5C918439@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-TqcZn5rsV/VKxFCmY0Wu
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Thu, 2006-01-19 at 23:40 -0800, Jason Evans wrote:
> 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 =20
> > 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 =20
> > where the
> > problem lies. What can I do to isolate where in the code the redzone
> > corruption is occurring?
>=20
> If you have the 'A' flag set, then you should be getting coredumps, =20
> unless gnome-system-monitor masks the SIGABRT signal. If you can't =20
> get coredumps, then you could try running gnome-system-monitor in =20
> gdb, with a breakpoint set in the branch of malloc.c:redzone_check() =20
> that calls abort().
Ah, I thought 'A' would do it, but I forgot about a signal handler in
libgtop. Thanks for the hint.
>=20
> > Additionally, do you have any example code that produces this kind of
> > redzone corruption? Thanks.
>=20
> Here is a quick hack that I wrote when testing the redzone code:
>=20
> ---
> #include <stdio.h>
> #include <stdlib.h>
>=20
> #define SIZE 25
>=20
> int
> main(void)
> {
> char *p;
> int i;
>=20
> p =3D (char *)malloc(SIZE);
> for (i =3D 1; i <=3D 16; i++) {
> p[-i] =3D 0x42 - i;
> }
> for (i =3D 0; i < 16; i++) {
> p[SIZE + i] =3D 0x43 + i;
> }
> free(p);
>=20
> return 0;
> }
> ---
>=20
> Note that redzones are currently defined to be 16 bytes, but there =20
> may be more than 16 bytes of trailing redzone space, depending on =20
> (size % 16).
Thanks!
Joe
--=20
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
--=-TqcZn5rsV/VKxFCmY0Wu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQBD0JSTb2iPiv4Uz4cRAg/gAJ96vdeIUDsc6cFSLVjCjeADFu8A/QCeLSHp
u+gPdVEmizxG8qJeXl79dAk=
=rnHi
-----END PGP SIGNATURE-----
--=-TqcZn5rsV/VKxFCmY0Wu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1137742995.75264.30.camel>