From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13163 invoked by alias); 15 Sep 2012 10:40:54 -0000 Received: (qmail 13153 invoked by uid 22791); 15 Sep 2012 10:40:53 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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, 15 Sep 2012 10:40:41 +0000 From: "dev at parallels dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug malloc/14581] glibc leaks memory and do not reuse after free (leading to unlimited RSS growth) Date: Sat, 15 Sep 2012 10:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dev at parallels dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: 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: 2012-09/txt/msg00122.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14581 --- Comment #2 from Kirill Korotaev 2012-09-15 10:40:39 UTC --- > Is this supposed to be a bug report or a trick question for CS students? :) You > claimed "there is no heap fragmentation", but the allocation/free pattern > you're performing seems like a classic fragmentation stress test pattern. I guess you haven't looked closely to the code and result... :( 1. Just print object addresses and allocated VMAs allocated using /proc/self/maps and you will find HUGE holes of not used RAM. 2. Do you realize that test NEVER has more then 100MB allocated, while RSS grows infinitely and to unbounded values? > There is no general-purpose allocation strategy that can avoid all instances of > pathological fragmentation, and this pattern is one that would be especially > hard to avoid without having special-cased it (and probably making malloc > behavior much worse for common real-world cases). No comments, see above. > Did you run into this issue in a real-world application, or did you construct this test as a worst-case? Yes, we hit this in real-life application. Very simple one, an application processing external requests from network. When a message arrives you allocate 556 bytes for message content to read from socket. Then you need 68KB to process the request. And then you free both. See the result. > By the way, the pathological fragmentation observed here does not seem specific > to glibc. It seems like it will occur with any allocator utilizing the basic > dlmalloc strategy. I just confirmed that the same issue happens with ours in musl libc. This pattern doesn't lead to unbound usage on TCmalloc, buddy allocator and original ptmalloc. See my next comment. Bug is in memalign. -- 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.