From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21074 invoked from network); 25 Apr 2004 21:13:17 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 25 Apr 2004 21:13:17 -0000 Received: (qmail 3194 invoked by alias); 25 Apr 2004 21:13:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19832 Received: (qmail 3161 invoked from network); 25 Apr 2004 21:13:09 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 25 Apr 2004 21:13:09 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [130.225.247.86] by sunsite.dk (MessageWall 1.0.8) with SMTP; 25 Apr 2004 21:13:8 -0000 Received: (qmail 17860 invoked from network); 25 Apr 2004 21:13:08 -0000 Received: from acolyte.scowler.net (216.254.112.45) by a.mx.sunsite.dk with SMTP; 25 Apr 2004 21:13:07 -0000 Received: by acolyte.scowler.net (Postfix, from userid 1000) id 9D31C7004A; Sun, 25 Apr 2004 17:12:39 -0400 (EDT) Date: Sun, 25 Apr 2004 17:12:39 -0400 From: Clint Adams To: Bart Schaefer Cc: zsh-workers@sunsite.dk, 245678-submitter@bugs.debian.org Subject: Re: Bug#245678: zsh: built-in rm -rf fills up the memory Message-ID: <20040425211239.GA5011@scowler.net> References: <20040424162150.GA4210@ay.vinc17.org> <20040425013647.GA28395@scowler.net> <1040425204530.ZM25792@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1040425204530.ZM25792@candle.brasslantern.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=-0.0 required=6.0 tests=BAYES_44 autolearn=no version=2.63 X-Spam-Hits: -0.0 > Assuming that it's the zsh/files module, the interesting thing there is > that, because it's a depth-first traversal, it allocates zsh-heap memory > to store all the file names in the directory, and it does so by growing > the allocated heap block once for each filename, by the length of that > filename (plus one). If ZSH_MEM was not defined at compile time, doing > this efficiently is left up to the underlying malloc() implementation [if > I'm reading mem.c correctly] and therefore could be subject to bugs we've > seen before where malloc never reclaims nor consolidates blocks when the > implementation repeatedly realloc()s in slightly larger chunks. > > I don't know anything about how zsh is compiled on debian or even why > the zsh/files module would be used (seemingly) by default, but in that's > probably the place to start looking. Yes, sorry. We're talking about when zsh/files is loaded explicitly. ZSH_MEM isn't being defined. Is there perhaps a mallopt() setting which would help?