Malloc Problem in glibc 2.2
Andreas Jaeger
aj@suse.de
Mon Jul 17 03:08:00 GMT 2000
>>>>> Wolfram Gloger writes:
Wolfram> Hello,
>> Forget the rlimit issues, I've just used them to illustrate a problem
>> I had with malloc.
Wolfram> OK.
>> Do I understand you correctly that you changed the meanings of the
>> environment variables MALLOC_MMAP_THRESHOLD_ and MALLOC_MMAP_MAX_ (and
>> the corresponding mallopt options) in a non compatible way - which
>> violates the documentation?
Wolfram> The effect of MALLOC_MMAP_THRESHOLD_ isn't changed.
It has been changed in the way that mmap is now also used for smaller
regions if sbrk fails.
Wolfram> I just want the default behaviour to be `address space completely
Wolfram> allocatable', that's why I changed the meaning of MALLOC_MMAP_MAX_.
>> Playing around with MALLOC_MMAP_MAX I noticed that it's impossible to
>> switch off mmap completly. Do you really define this as a "feature"
>> of glibc 2.2? IMO it's a bug.
Wolfram> OK, I see your point now, thanks. If setting MALLOC_MMAP_MAX_<=0
Wolfram> (whether via environment or via mallopt) would mean _no mmap
Wolfram> whatsoever_, would that be enough (IIRC that's the way used in Emacs,
Wolfram> for example)? I would submit a patch quickly then. I'll update the
Wolfram> documentation as well.
It would be according to the docu:
@item M_MMAP_MAX
The maximum number of chunks to allocate with @code{mmap}. Setting this
to zero disables all use of @code{mmap}.
@end table
Please send a patch,
Thanks,
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
More information about the Libc-hacker
mailing list