Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug#245678: zsh: built-in rm -rf fills up the memory
- X-seq: zsh-workers 19904
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Bug#245678: zsh: built-in rm -rf fills up the memory
- Date: Mon, 10 May 2004 11:16:23 +0100
- Cc: 245678-submitter@xxxxxxxxxxxxxxx
- In-reply-to: "Bart Schaefer"'s message of "Sun, 09 May 2004 16:51:03 PDT." <Pine.LNX.4.44.0405091647230.29962-100000@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> } [ h->used + (new - old) > HEAP_ARENA_SIZE ]
> } 63432 + (63504 - 63432) > 16360
>
> Aha! Note that h->used > HEAP_ARENA_SIZE all by itself!
>
> Comparing to HEAP_ARENA_SIZE is likely wrong, it should compare to the
> maximum of either HEAP_ARENA_SIZE or the previously-mmapped page size.
> I'm not entirely sure of that ...
>
> ... but that's why it begins re-zhalloc()-ing. In the non-MMAP case it
> falls back on realloc() when a single allocation exceeds HEAP_ARENA_SIZE.
>
> So what probably needs to happen to prevent the out-of-memory condition
> is that we need to explicitly munmap the old mmap'd block, somewhere.
>
> And then we need to emulate realloc() behavior somehow, in terms of
> knowing whether to actually re-mmap-and-copy or whether the existing
> mapped pages are large enough to contain the additional requested space.
Looks like a rewrite of hrealloc is definitely in order...
Does the bad behaviour go away if USE_MMAP is undefined?
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
Messages sorted by:
Reverse Date,
Date,
Thread,
Author