[fpc-devel] Access violation in fpmake
Michael Van Canneyt
michael at freepascal.org
Sun Nov 15 20:52:26 CET 2015
On Sun, 15 Nov 2015, Karoly Balogh (Charlie/SGR) wrote:
> On Sun, 15 Nov 2015, Michael Van Canneyt wrote:
>> Strange, I created a test before committing, and it ran fine. Well. I
>> reinstated line 1132. But according to logic, that line should not be
>> necessary. Maybe I am not properly seeing a case where it can go wrong.
> Wild try/guess just by looking at the code:
> If FList^[Index].FString is not nil (which is true after the System.Move()
> there), then at the next line at the assignment, there will be an attempt
> to reduce the reference count of the string before assigning the new one,
> and then it's a very likely case that the reference count of it will be
> zero, so the string is freed.
> Which means the string at FList^[Index+1] will be invalid, because
> System.Move() doesn't do anything with the reference counts, so at that
> point FList^[Index] and FList^[Index+1] are eachothers clones, but the
> reference count doesn't reflect that.
> Therefore that nil (and the pointer cast!) is very much required. The
> pointer cast is needed, so the string will be handled as pointer, and only
> the value is erased, but the refrence counts are untouched.
> Someone please fix me if I'm wrong. :)
But the fillword should have cleared all allocated memory in SetCapacity ?
So how can it be that there is a (valid) index where FList^[Index].FString is not nil ?
Wait, I think I have it.
When a delete is done, a move happens, but the item at Flist[Count] is not cleared.
Probably that is what causes this.
More information about the fpc-devel