Zsh Mailing List Archive
Messages sorted by:
Re: heap memory issues
- X-seq: zsh-workers 4684
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Phil Pennock <phil@xxxxxxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx (Zsh Development Workers)
- Subject: Re: heap memory issues
- Date: Tue, 24 Nov 1998 09:32:33 -0800
- In-reply-to: <199811212137.VAA00979@xxxxxxxxxxxxxxxxxxxxx>
- References: <199811212137.VAA00979@xxxxxxxxxxxxxxxxxxxxx>
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
} The debugging array h_m is declared to be:
} static int h_m;
} 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
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
} 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 :-)
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: