From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1040 invoked from network); 10 May 2004 00:00:43 -0000 Received: from ns2.primenet.com.au (HELO primenet.com.au) (96@203.24.36.3) by ns1.primenet.com.au with SMTP; 10 May 2004 00:00:42 -0000 Received: (qmail 3151 invoked from network); 9 May 2004 22:50:11 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by proxy.melb.primenet.com.au with SMTP; 9 May 2004 22:50:11 -0000 Received: (qmail 10358 invoked from network); 9 May 2004 22:49:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 May 2004 22:49:58 -0000 Received: (qmail 15484 invoked by alias); 9 May 2004 22:49:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19899 Received: (qmail 15471 invoked from network); 9 May 2004 22:49:47 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 9 May 2004 22:49:44 -0000 Received: (qmail 9789 invoked from network); 9 May 2004 22:49:41 -0000 Received: from unknown (HELO moonbase.zanshin.com) (root@167.160.213.139) by a.mx.sunsite.dk with SMTP; 9 May 2004 22:49:37 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [167.160.213.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i49MnMBL006741; Sun, 9 May 2004 15:49:22 -0700 Date: Sun, 9 May 2004 15:48:42 -0700 (PDT) From: Bart Schaefer Sender: schaefer@toltec.zanshin.com Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk cc: 245678-submitter@bugs.debian.org Subject: Re: Bug#245678: zsh: built-in rm -rf fills up the memory In-Reply-To: <20040508140207.GA25045@scowler.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Sat, 8 May 2004, Clint Adams wrote: > So, for example, if you have a directory with one hundred files with > 9-byte filenames, zsh might allocate one hundred 4096-byte areas. If that's really what's happening, it's a bug somewhere else, because zsh should only allocate another heap page if the current heap page doesn't have room for the requested growth. That is, 409 9-byte file names should need 4090 bytes (add 1 to each for the NUL byte), and it should put all 4090 of those bytes in the same 4096-byte heap block. It shouldn't allocate a new heap block until it gets to the 410th file, at which point it should allocate another 8192-byte block and copy the old block into it, and return the original 4096-byte block to the heap pool for re-use. (Where I'm assuming HEAP_ARENA_SIZE is 4096 here.) The following code should *never* be executed unless hrealloc() has previously been used to *shrink* a block: if (p + old < arena(h) + h->used) { if (new > old) { char *ptr = (char *) zhalloc(new); memcpy(ptr, p, old); #ifdef ZSH_MEM_DEBUG memset(p, 0xff, old); #endif unqueue_signals(); return ptr; } else { unqueue_signals(); return new ? p : NULL; } } Because unless we shrank, (p + old == arena(h) + h->used), as asserted by the DPUTS() that immediately follows. So, taking #ifdefs for MMAP into account, this code is what should run: if (h->used + (new - old) <= HEAP_ARENA_SIZE) { h->used += new - old; unqueue_signals(); return p; } else { char *t = zhalloc(new); memcpy(t, p, old > new ? new : old); h->used -= old; #ifdef ZSH_MEM_DEBUG memset(p, 0xff, old); #endif unqueue_signals(); return t; } And you're saying that (h->used + (new - old) <= HEAP_ARENA_SIZE) is always false, so the zhalloc() is always called? If that's not what you find to be the case, then the bug is elsewhere and we need to keep looking. If it is what you find, then there's a problem with h->used record-keeping, or something.