[fpc-devel]Problems with AnsiStrings (memory leak)

[Peter Vreman]

> FK> This is nearly impossible to fix because the problem is the memory 
> FK> fragmentation:
> FK> there are a lot of memory blocks allocated and deallocated but the
> FK> new blocks never fit into the available free blocks because there
> FK> is new data concatenated.
> 
> 
> I already supposed something like that and I already implemented your
> solution in some parts of the program, I just hoped there was a better
> solution.
> Anyway, I don't understand completely why this problem comes up. As
> far as I understood, when I add something to a string, the new string
> is placed to a new memory block (because it wouldn't fit in the
> original memory block). So far so good, but I think the memory loss
> shouldn't be so much.
> Have a look at this example (works like my sample program I posted):
> 
> First the string is set to "start" then a point "." is added in each step.
> AAAA, BBBB etc. marking previously used blocks (can be allocated):
> 
> "start"
> "AAAAAstart."
> "AAAAABBBBBBstart.."
> 
> shouldn't now fit the next block in the previously used blocks?
> 
> "start...BBBCCCCCCC"
> "DDDDDDDDstart....C" (new additional memory needed!)
> "DDDDDDDDEEEEEEEEEstart....."
> "start......EEEEEEFFFFFFFFFF" (again, no more memory needed)
> "GGGGGGGGGGGstart.......FFFF" (same here)
> 
> You see, never more memory than 3 times the real string is used (15 kb
> in my example and not >1 mb). Of course I don't know enough about
> memory organisation in fpc, but this seems quite logical to me. After
> two steps there should be always enough space left to re-use old
> blocks.
> 
> What makes the problem? Do you have problems re-using previously
> allocated (and then freed) blocks?
It's the all famous tradeoff problem memory<->speed.

We've received a new heap implementation from an user, some parts of it
will be implemented in the future as the compiler is more stable.

Peter