From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6751 invoked by alias); 8 Oct 2011 18:40:56 -0000 Received: (qmail 6744 invoked by uid 22791); 8 Oct 2011 18:40:55 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 08 Oct 2011 18:40:42 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13276] assertation failure in realloc when running out of virtual mappings Date: Sat, 08 Oct 2011 18:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00050.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13276 Rich Felker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugdal at aerifal dot cx --- Comment #1 from Rich Felker 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.