This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13276] assertation failure in realloc when running out of virtual mappings
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 08 Oct 2011 18:40:07 +0000
- Subject: [Bug libc/13276] assertation failure in realloc when running out of virtual mappings
- Auto-submitted: auto-generated
- References: <bug-13276-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13276
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2011-10-08 18:40:07 UTC ---
Making realloc fail in this case is not entirely a solution. The new memory has
already been allocated at this point, and the exact same error (inability to
munmap) could happen when trying to free this new allocation. (Maybe this isn't
possible, however, if the new allocation is either always on the heap or
performed atomically via mremap, i.e. if realloc never uses mmap+munmap.)
The most robust solution would be to ensure that each allocation is always its
own vma by putting guard pages between them, i.e. mmap(size+1page) with
PROT_NONE to begin with, then mmap size over top of that with MAP_FIXED.
Unfortunately this increases the kernelspace memory usage quite a bit (more
vmas) and adds an extra syscall to every allocation (probably an unacceptable
performance cost).
An alternative solution might be merge the region that munmap fails to free
into the free lists managed for non-mmap-serviced allocations.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.