Date: Sat, 21 Apr 2012 13:11:16 -0700 From: Jason Evans <jasone@freebsd.org> To: David Wolfskill <david@catwhisker.org> Cc: current@freebsd.org Subject: Re: <jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0" Message-ID: <7AD8956D-AD18-4CAB-9953-06E00185A7DA@freebsd.org> In-Reply-To: <20120421185402.GH1743@albert.catwhisker.org> References: <20120421185402.GH1743@albert.catwhisker.org>
index | next in thread | previous in thread | raw e-mail
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@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>
> However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>
> root@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@freebeast:/common/home/david # echo $?
> 134
> root@freebeast:/common/home/david # ls -lTio *.core
> ls: No match.
> root@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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7AD8956D-AD18-4CAB-9953-06E00185A7DA>