Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Feb 2014 21:06:50 -0800
From:      Jason Evans <jasone@freebsd.org>
To:        Lawrence Stewart <lstewart@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:  <78E18422-AA85-41D4-9DE8-D33D00881ABA@freebsd.org>
In-Reply-To: <52F45AA4.4000004@freebsd.org>
References:  <201401230247.s0N2lbkU098546@svn.freebsd.org> <52F45AA4.4000004@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
>>=20
>> Log:
>>  Update jemalloc to version 3.5.0.
>=20
> 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:
>=20
> <jemalloc>:
> =
/usr/local/poudriere/jails/head-amd64/usr/src/lib/libc/../../contrib/jemal=
loc/include/jemalloc/internal/arena.h:7
> 76: Failed assertion: "binind =3D=3D actual_binind"
> *** Signal 6
>=20
> and
>=20
> <jemalloc>:
> =
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h=
:776:
> Failed assertion: "binind =3D=3D actual_binind"
> Abort trap
>=20
> 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.
>=20
> 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?  If it=92s just the =
chromium build, is there any chance that this same failure would have =
occurred prior to the jemalloc 3.5.0 update?

If this is an application bug, it=92s probably due do a buffer overrun =
corrupting an adjacent page that contains page run metadata.  If it=92s =
a jemalloc bug, I=92m going to need to reproduce it and dig in; it=92s =
unlikely to be easy to diagnose.

Thanks,
Jason=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78E18422-AA85-41D4-9DE8-D33D00881ABA>