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<da...@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, Jason_______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
