Andreas Mohr a.mohr@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().
All in all, it's probably one more good reason for avoiding malloc in Wine.
On Wed, Jul 18, 2001 at 11:40:37AM -0700, Alexandre Julliard wrote:
Andreas Mohr a.mohr@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.
-
Alexandre Julliard -
Andreas Mohr