This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/22611] malloc might succeed and set errno to ENOMEM in case of heap allocation failure
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 15 Dec 2017 09:09:42 +0000
- Subject: [Bug malloc/22611] malloc might succeed and set errno to ENOMEM in case of heap allocation failure
- Auto-submitted: auto-generated
- References: <bug-22611-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22611
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
Flags| |security-
--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Aurelien Jarno from comment #0)
> tst-realloc tests, among others things that malloc and friends to not set
> errno to ENOMEM in case of successful memory allocation. This test always
> fail on sparc64 with "Error: errno is set but should not be".
Isn't this test invalid?
> On sparc64 it happens that, for a reason I don't really understand, when
> running processes by explicitly calling ld.so, all the heap allocation fail,
> ie the call to brk return an unchanged address.
ppc64 has the same problem, but there it was more obvious because brk would
succeed, but not always map the memory. It happens if ld.so is mapped close to
the top of the usable address space, and the heap still has to come after that.
This can result in unexpectedly small heap sizes and brk failures.
These VM layout issues are kernel bugs which will break static PIE binaries,
too.
--
You are receiving this mail because:
You are on the CC list for the bug.