From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23672 invoked from network); 24 Nov 1998 17:40:37 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 24 Nov 1998 17:40:37 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id MAA13027; Tue, 24 Nov 1998 12:37:58 -0500 (EST) Resent-Date: Tue, 24 Nov 1998 12:37:58 -0500 (EST) From: "Bart Schaefer" Message-Id: <981124093233.ZM9433@candle.brasslantern.com> Date: Tue, 24 Nov 1998 09:32:33 -0800 In-Reply-To: <199811212137.VAA00979@athenaeum.demon.co.uk> Comments: In reply to Phil Pennock "heap memory issues" (Nov 21, 9:37pm) References: <199811212137.VAA00979@athenaeum.demon.co.uk> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Phil Pennock , zsh-workers@math.gatech.edu (Zsh Development Workers) Subject: Re: heap memory issues MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"so0g42.0.RB3.rxkMs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4684 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 21, 9:37pm, Phil Pennock wrote: } Subject: heap memory issues } } If I'm right and these are bugs, someone more comfortable with actually } altering the code might want to write the patches. But first I want } Bart to rip holes in my logic and work out my mistakes. :^) Chuckle. I'm not really all that well-versed in the memory code, and I was pretty busy with other stuff the last several days, but here are some random rips. } The debugging array h_m is declared to be: } static int h_m[1025]; } It seems to be used for tracing the number of allocations of a given } size; however, with an H_ISIZE == sizeof(long), [assuming 4] then } scanning mem.c, it's 3/4 unused. The first 1024/H_ISIZE entries and } 1024 can be filled, the rest will never change from 0. That's right. It appears from the code in bin_mem() that halloc() should be using h_m[size < (1024 * H_ISIZE) ? (size / H_ISIZE) : 1024]++; } Also, for 64-bit platforms, might alignment constraints require H_ISIZE } to be sizeof(long long), or can all of them use 32-bit alignment? It would probably be useful to have a configure test for the actual size required for correct alignment on any given platform. I may be able to dig one up (somebody remind me later, please). } Whilst I haven't tested this, it looks upon reading as though there are } some problems if hrealloc()ing a memory-block that is larger than } HEAP_ARENA_SIZE. [...] If a previous hrealloc() has gone from greater than } HEAP_ARENA_SIZE to less than HEAP_ARENA_SIZE then a new arena will have } been allocated (lines 338-345), so h->used can't be less than } HEAP_ARENA_SIZE for a big hunk, *BUT* there is the problem that the new } arena thus allocated will be smaller than HEAP_ARENA_SIZE and the } zfree(h, HEAPSIZE) in line 269 now frees too much memory. I don't see any immediate flaws in this reasoning, except for one: The second parameter to zfree() is almost completely meaningless. :-) This parameter is only used when ZSH_MEM is defined, and then it's only used to try to consolidate small blocks so a larger block can be recovered. It's only a problem for the second parameter of zfree() to be wrong when it's also less than (M_ISIZE * M_NSMALL). See line 854, which gates the zfree() code extending down to line 936. } Hrm, lines 314-316 are: } DPUTS(!h, "BUG: hrealloc() called for non-heap memory."); } DPUTS(h->sp && arena(h) + h->sp->used > p, } "BUG: hrealloc() wants to realloc pushed memory"); } If the first DPUTS prints (ie, non-heap memory) then won't this } dereference a null-pointer? Yes, but so will other code later, so the whole point is to flush out that error message. } Lines 318-325 handle reallocating from the middle of an arena -- } should this do a memset() to 0xff if ZSH_MEM_DEBUG, or is that only for } memory ranges that extend to the end of an arena? That one I can't (really: don't want to stare at this long enough to :-) answer. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com