Re: heap memory issues

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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