This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Malloc Problem in glibc 2.2


>>>>> Wolfram Gloger writes:

Wolfram> Hello,
>> looking at a problem with getrlimit/setrlimit, I noticed that malloc
>> in glibc 2.2 doesn't work as expected.  The appended program gives
>> with a glibc 2.1 system:
>> 
>> gromit:/tmp/pr:[0]$ ./rlimit 
>> rlim_cur 1240, rlim_max: 2147483647
>> malloc returned: (nil)
>> 
>> But the current glibc 2.2 version does:
>> $ LD_LIBRARY_PATH=. elf/ld-linux.so.2 /tmp/pr/rlimit
>> rlim_cur 1240, rlim_max: 2147483647
>> malloc returned: 0x40117008

Wolfram> I consider this a feature, not a bug :-).  The increasing bunch of
Wolfram> lucky people with >2GB 32bit systems will probably agree with me, too.
Wolfram> All you have done with rlimit is to limit the `classical' heap even
Wolfram> further than the `normal' 1GB, so the non-linear heap is now used.

Forget the rlimit issues, I've just used them to illustrate a problem
I had with malloc.

>> Why is glibc 2.2 using mmap and glibc 2.1 not?

Wolfram> If sbrk() would fail on 2.1, there could only be n_mmaps_max further
Wolfram> allocations.  No matter how large we would increase n_mmaps_max, I'm
Wolfram> sure someone would complain that her machine still can't allocate all
Wolfram> the available memory.

Wolfram> So, I changed the meaning of n_mmaps_max to mean the following limit:

Wolfram> In 2.1:
Wolfram> n_mmaps_max was a hard limit on the number of chunks alocated with
Wolfram> mmap().  Beyond the limit, if sbrk() failed, malloc would return 0.

Wolfram> In 2.2:
Wolfram> Until n_mmaps_max is reached, mmap() is used in preference of sbrk().
Wolfram> When n_mmaps_max is reached or passed, sbrk() is _always_ tried first.
Wolfram> However, mmap() is now always tried as a last resort before giving up
Wolfram> and returning 0.

Wolfram> So, the parameter is still useful for avoiding mmap() on a system
Wolfram> where it's very costly (Linux surely isn't such a system), but it
Wolfram> doesn't limit the total number of chunks that can be allocated.

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?

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.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]