<jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
Aleksandr Rybalko
ray at dlink.ua
Sat Apr 28 12:09:40 UTC 2012
On Sat, 21 Apr 2012 13:11:16 -0700
Jason Evans <jasone at freebsd.org> wrote:
>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>> > After applying Dimitry Andric's patches to contrib/jemalloc and
>> > replacing /usr/bin/as with one built last Sunday, I was finally(!)
>> > able to rebuild head as of 234536:
>> >
>> > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT
>> > #797 234536M: Sat Apr 21 10:23:33 PDT 2012
>> > #root at freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>> >
>> > However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>> >
>> > root at freebeast:/common/home/david # (cd /var/tmp && rm -fr obj &&
>> > mkdir obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf
>> > -)
>> >
>> > it ran for a while, then:
>> >
>> > <jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
>> > Abort (core dumped)
>> > root at freebeast:/common/home/david # echo $?
>> > 134
>> > root at freebeast:/common/home/david # ls -lTio *.core
>> > ls: No match.
>> > root at freebeast:/common/home/david #
>> >
>> > So ... no core file, apparently.
>> >
>> > freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>> > jemalloc_arena.c freebeast(10.0-C)[3]
>> >
>> > No file named "jemalloc_arena.c", either.
>> >
>> > But contrib/jemalloc/src/arena.c contains a function,
>> > arena_chunk_validate_zeroed():
>> >
>> > 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 = (size_t *)((uintptr_t)chunk +
>> > (run_ind << LG_PAGE)); 180
>> > 181 for (i = 0; i < PAGE / sizeof(size_t); i++)
>> > 182 assert(p[i] == 0);
>> > 183 }
>> >
>> > Thoughts?
>>
>> I received a similar report yesterday in the context of filezilla,
>> but didn't get as far as reproducing it. I think the problem is in
>> chunk_alloc_dss(), which dangerously claims that newly allocated
>> memory is zeroed. It looks like I formalized this bad assumption in
>> early 2010, though the bug existed before that. It's a bigger deal
>> now because sbrk() is preferred over mmap(), so the bug has
>> languished for a couple of years. I'll get a fix committed today
>> (and revert the order of preference between sbrk() and mmap()).
>>
>> By the way, I wonder why not everyone hits this (I don't).
>>
>> Thanks,
>> Jason_______________________________________________
>> freebsd-current at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscribe at freebsd.org"
Hi,
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)
After "#ifdef" of that function body, box behave good (seems) :)
WBW
--
Alexandr Rybalko <ray at dlink.ua>
aka Alex RAY <ray at ddteam.net>
More information about the freebsd-current
mailing list