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/13276] assertation failure in realloc when running out of virtual mappings


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.


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