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_at_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;) >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=167064 > > 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. > > 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. > > 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. :) > > 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. > > 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, JasonReceived on Fri Apr 20 2012 - 17:54:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC