This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12232] setrlimit interferes with malloc


http://sourceware.org/bugzilla/show_bug.cgi?id=12232

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |jakub at redhat dot com
         Resolution|                            |INVALID

--- Comment #3 from Jakub Jelinek <jakub at redhat dot com> 2010-11-18 20:26:54 UTC ---
Why not?  If you call malloc before the setrlimit call and then free, it in
many cases will leave some heap pages (either brk area or mmap) mmapped in the
address space, so following malloc, if it can be satisfied from those pages,
can succeed.
If on the other side there are is not enough space in the current pages to
satisfy the request and new brk extension or mmap will be forbidden by the
kernel because of exceeding address space limit, of course malloc will fail.

There is nothing malloc code can do about it.  Scanning all the time
/proc/maps, calling getrlimit and counting if there is room, in addition to be
terribly slow, wouldn't buy you anything, if the kernel won't allow you to
allocate anything, the userspace can't workaround it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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