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: "dlstevens 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 19:59:27 -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 dlstevens at us dot ibm dot com 2006-03-14 19:59 -------
"The user" would be me, and I didn't get incorrect results from a man page.
The problem, as I said in the first two entries, was that I was never able
to get a NULL return from malloc(). I always either got "success" (in some
cases without actually getting memory) or a segmentation violation. If I
recall, a malloc() that exceeded the soft limit returned the same pointer as
an already-allocated and not freed prior malloc(), which would be wrong.
It certainly is possible that I had a misconfiguration on my system, and I lost
the context beyond what I wrote here more than a year ago. So, closing the bug
is not unreasonable, but I'd be happier if you had a test that manipulates
the soft limits (correctly, if what I did was wrong) and results in a
successful allocation or NULL return from malloc(), always. No segmentation
faults, no garbage returns, etc.
In other words, if you can demonstrate a case where setting a soft limit
results in malloc() returning NULL (ever), then I think your test will be
farther than I ever got, and I'd be happy with having the bug closed. :-)
I don't care what the man page says. :-)
--
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.