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/214] sbrk() doesn't detect brk() failures. Malloc doesn't handle sbrk() failures


------- 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.


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