cvs commit: src/lib/libc/stdlib malloc.c

[Giorgos Keramidas]

On 2006-01-15 01:05, Jason Evans <jasone at 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 :)