Date: Sat, 28 Apr 2012 11:29:01 -0700 From: Jason Evans <jasone@FreeBSD.org> To: Aleksandr Rybalko <ray@dlink.ua> Cc: current@freebsd.org Subject: Re: <jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0" Message-ID: <C8857CA7-44D5-4EB0-A1E2-DE0E0F6A673E@FreeBSD.org> In-Reply-To: <20120428150941.e0464900.ray@dlink.ua> References: <20120421185402.GH1743@albert.catwhisker.org> <7AD8956D-AD18-4CAB-9953-06E00185A7DA@freebsd.org> <20120428150941.e0464900.ray@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 28, 2012, at 5:09 AM, Aleksandr Rybalko wrote:
>>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>>>>=20
>>>> But contrib/jemalloc/src/arena.c contains a function,
>>>> arena_chunk_validate_zeroed():
>>>>=20
>>>> 175 static inline void
>>>> 176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
>>>> run_ind) 177 {
>>>> 178 size_t i;
>>>> 179 UNUSED size_t *p =3D (size_t *)((uintptr_t)chunk +
>>>> (run_ind << LG_PAGE)); 180
>>>> 181 for (i =3D 0; i < PAGE / sizeof(size_t); i++)
>>>> 182 assert(p[i] =3D=3D 0);
>>>> 183 }
>=20
> maybe it somehow related to low count of free memory, because I see
> that very frequently on my box. (Atheros AR7242 mips32be with 32M of
> RAM)
>=20
> After "#ifdef" of that function body, box behave good (seems) :)
Yes, arena_chunk_validate_zeroed() (which is debug-only code) has the =
side effect of faulting in untouched pages, so it potentially increases =
physical memory usage. In practice, this sanity checking has saved =
jemalloc from regressions that would otherwise manifest as mysterious =
application memory corruption (and would have prevented even more =
regressions, had it existed earlier). You can disable it and many other =
performance-sacrificing debug features by defining MALLOC_PRODUCTION in =
/etc/make.conf.
Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C8857CA7-44D5-4EB0-A1E2-DE0E0F6A673E>