This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/214] sbrk() doesn't detect brk() failures. Malloc doesn't handle sbrk() failures
- From: "rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 14 Mar 2006 18:34:33 -0000
- Subject: [Bug libc/214] sbrk() doesn't detect brk() failures. Malloc doesn't handle sbrk() failures
- References: <20040610193839.214.dlstevens@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rsa at us dot ibm dot com 2006-03-14 18:34 -------
Synopsis:
o The brk() and sbrk() functions are working as designed in GLIBC and in the
Linux kernel though the man-page should be updated to reflect the actual behavior.
o A sufficiently small program and data segment will be given a free page of
data-segment data (as accounted by the kernel) due to segment alignment by 'ld'.
(refer to the information in previous bug entries).
o The kernel only honors page granularity with regard to RLIMIT_DATA rlim_cur
soft limit. If you ask for a (PAGE + 1) rlim_cur soft-limit the kernel will
honor brk() requests up to (PAGE * 2); This is because the kernel allocates
memory in pages.
o /proc/self/Status : VmData is in kB, so if you want to use it as a basis for
your rlim_cur soft-limit then multiply VmData by 1024. Setting the soft-limit
to VmData will prevent brk() calls beyond the data-segment size already required
by the program. VmData + 1 will set the soft-limit to VmData + PAGE.
I'm pretty much done with this bug and I think it can be closed as INVALID.
Basically the user looked at the man-page and was misled as to the functionality.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=214
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.