Date: Sun, 15 Jan 2006 16:06:12 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Pascal Hofstee <caelian@gmail.com> Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060115140612.GA84290@flame.pc> In-Reply-To: <EDDCE13D-B4EF-450A-B889-AB50CB70D8D5@FreeBSD.org> References: <20060112182804.GA1047@flame.pc> <20060113012900.GA16082@flame.pc> <554CC8A8-35FB-424A-B883-505C26ECBBE8@FreeBSD.org> <20060114213238.GA15253@flame.pc> <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org> <43C97BCA.6030201@gmail.com> <20060115013248.GA28047@flame.pc> <43C9BDE3.8030408@gmail.com> <20060115032810.GA99817@flame.pc> <EDDCE13D-B4EF-450A-B889-AB50CB70D8D5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-01-15 01:05, Jason Evans <jasone@FreeBSD.org> wrote: >On Jan 14, 2006, at 7:28 PM, Giorgos Keramidas wrote: >> >> Jason, >> >> is this related to the malloc changes in any way. I'm curious >> why the default return type of `int' wasn't a problem so far. >> Has the definition of userland pointers changed recently from >> a type that could fit in an `int' to something larger? > > On amd64, jemalloc uses mmap() to get chunks of memory to carve > up. It's possible that these chunks are above 4 GB, which > means that the high bits are important, but sizeof(int) is 4, > not large enough to store such a pointer. With sbrk(), the > addresses are rather small, so the high bits would never be > used in that case. This bug would slip by with most (all?) > other allocators, and would also slip by jemalloc if USE_BRK > were defined for amd64 in malloc.c. Ah, I see! That explains why rolling jemalloc back 'fixes' the bug, quite nicely. Thanks :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060115140612.GA84290>