This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/214] sbrk() doesn't detect brk() failures. Malloc doesn't handle sbrk() failures
- From: "dlstevens at us dot ibm dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 18 Jun 2004 17:35:49 -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 sources dot redhat dot com
------- Additional Comments From dlstevens at us dot ibm dot com 2004-06-18 17:35 -------
I looked a little more into this and I found code for Linux in glibc that is
supposed to remap brk to "-1" on error cases, so I'm no longer sure what's
going on here. What was failing in my test is that sbrk() didn't return "-1"
when the soft RLIMIT_DATA limit should have been exceeded, and strace() showed
brk() returning the break point, not a negative value, when this happened.
However, if the linux-specific __brk() code is on my system, that should've
given a "-1" to sbrk() as it expects and sbrk() itself should've returned "-1",
which isn't what I saw. I also had different results when using the static
library versus the dynamic library.
I'll put together a more comprehensive test program and run it on a fresh
install to see if the problem goes away, or if I can isolate what exactly is
going on. I was never able to trigger a malloc "NULL" return by manipulating
the soft limit-- only resulted in a SEGV within malloc when I got a failre at
all, so something appears not to be happy.
--
http://sources.redhat.com/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.