From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11231 invoked from network); 8 Sep 2008 21:19:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Sep 2008 21:19:55 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 89504 invoked from network); 8 Sep 2008 21:19:34 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Sep 2008 21:19:34 -0000 Received: (qmail 26531 invoked by alias); 8 Sep 2008 21:19:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25635 Received: (qmail 26512 invoked from network); 8 Sep 2008 21:19:19 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 8 Sep 2008 21:19:19 -0000 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by bifrost.dotsrc.org (Postfix) with ESMTP id 03A91802710A for ; Mon, 8 Sep 2008 23:19:15 +0200 (CEST) Received: by ey-out-2122.google.com with SMTP id 25so789367eya.3 for ; Mon, 08 Sep 2008 14:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding:from; bh=zsayRQky7yEzj3fhMLvVeL7jf+GU+qJOni/ZeN+9ypI=; b=AmgCW5+HfmFSvhJ8sblkiIX/1G/DMYy4kNNvEZFttdGaR2D5aWUFAwBN73lJws2GvS qohbGxmcGhf9CHAxx+BoxB10iBtEvl8TT3iLawI5O+tGbvh8bfUG0y8bQRkSJiQFLLx6 9goLG46pqU8qMu1I0VOGtFHXmySgQZhfyfFu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:from; b=Q1ms+jcIVmdIksVhj5RpZ4hZf9j/4MW1HvfV6EFmE8QNgu1D7R1XlZL+6C+9trpOQ4 0nfWb4dA9cxuxtw9nJPW7X3rd2LPKnRNFJuaPQLj4zaOWrlqdfk+h8K3AuUoeBuZqk9D iwHX3CxIUcTeO5h8uPPx+ZIcfhBWfI7tk1UvQ= Received: by 10.181.11.3 with SMTP id o3mr11333921bki.105.1220908754859; Mon, 08 Sep 2008 14:19:14 -0700 (PDT) Received: from ?192.168.1.3? ( [87.123.241.11]) by mx.google.com with ESMTPS id 28sm4216672fkx.1.2008.09.08.14.19.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Sep 2008 14:19:13 -0700 (PDT) Message-ID: <48C596DA.9050202@gmail.com> Date: Mon, 08 Sep 2008 23:19:22 +0200 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: [PATCH] compsys maps anonymous memory and never frees it References: <48BDF1EC.4050204@gmail.com> <080904072526.ZM12341@torch.brasslantern.com> <48C38F88.9040202@gmail.com> <200809071504.36084.arvidjaar@newmail.ru> In-Reply-To: <200809071504.36084.arvidjaar@newmail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit From: =?ISO-8859-1?Q?=22xRaich=5Bo=5D=B2x=22?= X-Virus-Scanned: ClamAV 0.92.1/8194/Mon Sep 8 22:40:30 2008 on bifrost X-Virus-Status: Clean Andrey Borzenkov wrote: > On Sunday 07 September 2008, xRaich[o]²x wrote: > >> Bart Schaefer wrote: >> >>> On Sep 4, 1:04am, =?ISO-8859-1?Q?Bj=F6rn_Herzig?= wrote: >>> } >>> } I looked at the problem a little closer. Zsh does not call mmap to >>> } allocate them and they dont get allocated when completion happens but >>> } when the next command gets issued. >>> >>> > > I was able to more or less reproduce it on Linux; but now after your patch > I get what looks like memory leak. Here are heaps after several memory > intensive completions: > > Address Kbytes RSS Anon Locked Mode Mapping > 08048000 608 - - - r-x-- zsh > 080e0000 16 - - - rw--- zsh > 080e4000 92 - - - rw--- [ anon ] > 09d6a000 672 - - - rw--- [ anon ] > > [...] > > Address Kbytes RSS Anon Locked Mode Mapping > 08048000 608 - - - r-x-- zsh > 080e0000 16 - - - rw--- zsh > 080e4000 92 - - - rw--- [ anon ] > 09d6a000 5340 - - - rw--- [ anon ] > b6a68000 15464 - - - rw--- [ anon ] > > > Compare this with version without patch: > > Address Kbytes RSS Anon Locked Mode Mapping > 08048000 528 - - - r-x-- zsh > 080cc000 16 - - - rw--- zsh > 080d0000 88 - - - rw--- [ anon ] > 099df000 744 - - - rw--- [ anon ] > > [...] > > Address Kbytes RSS Anon Locked Mode Mapping > 08048000 528 - - - r-x-- zsh > 080cc000 16 - - - rw--- zsh > 080d0000 88 - - - rw--- [ anon ] > 099df000 5520 - - - rw--- [ anon ] > b6adb000 15464 - - - rw--- [ anon ] > b7a05000 12 - - - rw--- [ anon ] > b7b46000 108 - - - rw--- [ anon ] > > So it looks like we still have some memory leak somewhere. > Are you sure that those segments aren't those dlopen allocates when loading modules? they are actually created by the operating system and needed. What i find a bit disturbing is that whenever loading modules one segment gets unmapped by munmap with two times its size. I think the operating system will catch that but maybe this is possible to fix somehow. i wrote a little dtrace script that keeps track of every mapped segment and checks if they get munmapped with the correct size. Everything except the mentioned munmap seems to work after the patch. Regards, Björn