Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Jan 2006 01:05:38 -0800
From:      Jason Evans <jasone@FreeBSD.org>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
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:  <EDDCE13D-B4EF-450A-B889-AB50CB70D8D5@FreeBSD.org>
In-Reply-To: <20060115032810.GA99817@flame.pc>
References:  <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Jason



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EDDCE13D-B4EF-450A-B889-AB50CB70D8D5>