Date: Mon, 10 Feb 2014 11:11:34 +1100 From: Lawrence Stewart <lstewart@freebsd.org> To: Jason Evans <jasone@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r261071 - in head: contrib/jemalloc contrib/jemalloc/doc contrib/jemalloc/include/jemalloc contrib/jemalloc/include/jemalloc/internal contrib/jemalloc/src include lib/libc/gen lib/libc/... Message-ID: <52F81936.6030703@freebsd.org> In-Reply-To: <78E18422-AA85-41D4-9DE8-D33D00881ABA@freebsd.org> References: <201401230247.s0N2lbkU098546@svn.freebsd.org> <52F45AA4.4000004@freebsd.org> <78E18422-AA85-41D4-9DE8-D33D00881ABA@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/07/14 16:06, Jason Evans wrote: > On Feb 6, 2014, at 8:01 PM, Lawrence Stewart <lstewart@freebsd.org> > wrote: >> On 01/23/14 13:47, Jason Evans wrote: >>> Author: jasone Date: Thu Jan 23 02:47:36 2014 New Revision: >>> 261071 URL: http://svnweb.freebsd.org/changeset/base/261071 >>> >>> Log: Update jemalloc to version 3.5.0. >> >> I suspect that this commit is related to the assertion failures >> I've been seeing on recent head when I updated from r260427 to >> r261453. Here's two I noticed today: >> >> <jemalloc>: >> /usr/local/poudriere/jails/head-amd64/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:7 >> >> 76: Failed assertion: "binind == actual_binind" >> *** Signal 6 >> >> and >> >> <jemalloc>: >> /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:776: >> >> Failed assertion: "binind == actual_binind" >> Abort trap >> >> I seem to be able to reproduce the first one readily when >> poudriere tries to build chromium so I can provide more info and >> help test ideas. >> >> Cheers, Lawrence > > Are the failures you saw happening only for the chromium build, or > have you seen that same failure for other things as well? Other things as well. The second example came from a completely unrelated app - dnsmasq if I remember correctly. The assertion failures are not deterministic. I do recall the machine was using a fairly substantial amount of swap at the time which might be relevant, as I haven't noted a failure recently since rebooting the laptop. > If this is an application bug, it’s probably due do a buffer overrun > corrupting an adjacent page that contains page run metadata. If it’s > a jemalloc bug, I’m going to need to reproduce it and dig in; it’s > unlikely to be easy to diagnose. I'll keep an eye out for further failures and see if I can figure out a reproduction recipe. Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F81936.6030703>