Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Apr 2012 12:54:17 -0700
From:      Jason Evans <jasone@freebsd.org>
To:        Dimitry Andric <dim@FreeBSD.org>
Cc:        Michael Pounov <misho@aitbg.com>, current@FreeBSD.org
Subject:   Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
Message-ID:  <A7FB12C8-20FE-405A-88D7-4B872E9544F5@freebsd.org>
In-Reply-To: <4F91BDE1.4080802@FreeBSD.org>
References:  <20120420125718.GD1582@albert.catwhisker.org> <20120420165558.b51c8b66.misho@aitbg.com> <4F91BDE1.4080802@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote:
> On 2012-04-20 15:55, Michael Pounov wrote:
>> On Fri, 20 Apr 2012 05:57:18 -0700
>> David Wolfskill<david@catwhisker.org>  wrote:
> ...
>>> The update after 234416 was to 234454; the attempted buildworld =
failed:
> ...
>>> /usr/bin/as: out of memory allocating 4194304 bytes after a total of =
524288000 bytes
>> yep, I sent PR for this issue;)
>>=20
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167064
>=20
> The root cause of this is the new jemalloc import in r234370.  In
> contrib/jemalloc/src/chunk.c, this defines a global variable called
> 'chunksize'.  At run-time, this turns out to have a value of 4194304, =
at
> least on my i386 system.
>=20
> However, GNU as *also* has a global variable called 'chunksize', with =
a
> very different intent: it is the default chunk size for its so-called
> "obstacks", an internal implementation detail.  It is set to zero in
> contrib/binutils/gas/as.c, but normally ends up as 4096 during further
> initialization.
>=20
> Now, because the variable from jemalloc ends up in libc.a, and
> /usr/bin/as is statically linked, the jemalloc variable overrides the
> one from GNU as.  This causes as to allocate 4 MiB chunks instead of 4
> KiB chunks for all its internal processing, and you can guess what
> happens with a reasonably large input file. :)
>=20
> I think the best solution would be for jemalloc to avoid using obvious
> names like "chunksize" for its globals, because it is basically a
> library that could be linked to any sort of program out there.
>=20
> For example, it could prefix all its internal-use only globals with
> "jemalloc_" or some other mangling scheme.  Jason, any thoughts?

jemalloc has optional namespace mangling support built in for just this =
reason.  I'll turn it on, hopefully today.

Thanks,
Jason=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A7FB12C8-20FE-405A-88D7-4B872E9544F5>