glibc bug mmap/malloc

Andreas Mohr a.mohr at mailto.de
Wed Jul 18 15:15:55 CDT 2001


On Wed, Jul 18, 2001 at 11:40:37AM -0700, Alexandre Julliard wrote:
> Andreas Mohr <a.mohr at mailto.de> writes:
> 
> > You can clearly see that malloc() is able to squeeze up to 10232 bytes
> > into the memory range just before the mmap()ed area, but when it gets
> > slightly larger, it is NOT capable of switching to an entirely different
> > memory area, throws its arms up in desperation and simply returns a shabby
> > NULL.
> > It only uses a new memory area in case the values get *much* larger,
> > i.e. at least 131060 bytes.
> > 
> > This is a BUG.
> > (IMHO)
> > What else should it be ?
> 
> This is more a limitation of the malloc implementation than an actual
> bug. malloc uses brk() to allocate memory, but brk() cannot grow past
> an mmapped area, so malloc fails. With a standard Linux app shared
> libraries are mapped high in memory (usually from 0x40000000) so the
> malloc limit is about 1Gb; but if stuff is mapped lower, malloc
> capacity is reduced. The reason it works for mallocs larger than 128Kb
> is that glibc uses anonymous mmaps to reserve space for these instead
> of brk().
Ah, this is exactly what I was silently afraid of.
That it's not a bug, but simple braindamage.
(ok, admittedly it's not as easy as that, but still...)

After all we're talking about libc, which is used by bazillions of programs,
so you could bet at least someone has noticed earlier and fixed bugs already,
which is why it's very likely that more or less only "features" remain.

> All in all, it's probably one more good reason for avoiding malloc in
> Wine.
Somehow I can't get rid of the feeling that there's missing a "very" or
a "very much" at least *somewhere* in this sentence.

I mean, come on: why did they bother to implement malloc() at all
if the resulting architecture is THAT broken ?

Nobody with their minds in right shape would ever use it then, right ?

Get rid of it, period.

-- 
Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
Microsoft Windows: Made for the Internet
The Internet: Made for Unix




More information about the wine-devel mailing list