From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13252 invoked from network); 10 May 2004 16:53:27 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 10 May 2004 16:53:27 -0000 Received: (qmail 18906 invoked from network); 10 May 2004 16:53:16 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 10 May 2004 16:53:16 -0000 Received: (qmail 17988 invoked by alias); 10 May 2004 16:53:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19908 Received: (qmail 17968 invoked from network); 10 May 2004 16:53:14 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 10 May 2004 16:53:11 -0000 Received: (qmail 18363 invoked from network); 10 May 2004 16:52:55 -0000 Received: from unknown (HELO moonbase.zanshin.com) (root@167.160.213.139) by a.mx.sunsite.dk with SMTP; 10 May 2004 16:52:53 -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 i4AGqbHL007492; Mon, 10 May 2004 09:52:37 -0700 Date: Mon, 10 May 2004 09:51:53 -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: <28310.1084205953@csr.com> 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=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Mon, 10 May 2004, Peter Stephenson wrote: > This is all ghastly even by zsh standards. Well, that's what comes of having glued MMAP into the hrealloc() algorithm piecemeal. Probably what should have been done was just to #ifdef the entire function body. > What we should do is the equivalent of realloc as an #else of the code > above --- mmap a larger chunk, unmap the old one, and return the new > one. I think I said that, though I hadn't got so far as to pinpoint where it needed to happen. > However, I don't think even *that* is the basic problem. I think this: > > old = (old + H_ISIZE - 1) & ~(H_ISIZE - 1); > new = (new + H_ISIZE - 1) & ~(H_ISIZE - 1); > > is wrong --- it should be the heap size here, not H_ISIZE which is > simply sizeof(union mem_align), which is probably only 4 or 8 words. It took me a while staring at this to decide that it was doing the right thing, but I came to the conclusion that it's only actually _wrong_ if HEAP_ARENA_SIZE is _not_ a multiple of H_ISIZE. And even then I'm pretty sure "wrong" just means "inefficient". > We only need to reallocate to heap size boundaries That's correct, but we _do_ only reallocate to heap size boundaries in the non-MMAP case. I think. It's only the MMAP'd code, which as I said was pasted in long after the original algorithm was written, that botches it. > I might be tempted by proposed solutions involving the complete removal > of hrealloc. Which would mean what, exactly? Never grow heap blocks? (Note that I didn't begin with "why".)