Andres Kroonmaa wrote:
> The problem is with robustness of mempools to misuse of freed items.
> libmalloc's free() is probably immune to multiple free() calls for
> the same item, as long as freed memory has not been given to some
> other caller. In my design, as freelist is kept as linklist,
> 1) multiple Frees on the same item corrupts freelist consistency.
> 2) If item is tampered with after Free(), chunk's freelist can also
> get corrupted.
> So I ask: is it ok to live with (2) and make it responsibility of a
> coder to make sure and track misuse of freed items, or should I drop
> the idea of keeping zero-ram-overhead freelist inside freed items?
> I'd rather not drop the free listnode approach, as it conserves
> quite alot of memory (or cpu overhead, if using bitmaps).
My vote is that we live with 2, and then have an option to completely
disable memory pools to be able to use standard malloc debuggers to find
such problems.
disabled == alloc/free functions recoded into macros making calls to
malloc/free. This to make sure the calling function is the function
making the memory reservation, not a intermendiate library like
MemPools...
Spent most of the day yesterday to try to find one of those odd memory
corruption problem, but I never managed to find it. Something overflowed
a buffer and stomped on mallocs pointers, and sometime later a segfault
was seen when mempools was releasing memory.. And today I did not see
the problem, but I am not aware of having fixed it...
/Henrik
Received on Thu Nov 09 2000 - 16:23:44 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:57 MST