The move will not crash, unless you write to memory not owned by your app (then the OS will trap it). Most times crossing the boundaries of one mem block, will keep you in mem owned by your app.
Since very likely after the allocated block there will be other mem managed by fpc, there will be an internal fpc structure. So if you write to much, then it is only a question of time until fpc accesses the node that was overwritten.
and i thought i was aware of all this stuff.. does internal and application-memory get mixed when not using c-mem also?
ok, i wrapped getmem, move and freemen in order to be sure i wasn't doing anything bad with illegal access:
data getmem: 00007FFFF7F812B0 1600
// ....
tmpbytes getmem: 00007FFFF7EBD180 288
move 00007FFFF7F812B0 to 00007FFFF7EBD180: 288
move 00007FFFF7EBD180 to 00007FFFF7F812D0: 288
freemem 00007FFFF7EBD180
EDIT:
maybe i should explain what the code does..
it adds a slot between elements at index i by moving all data at and behind i to i+1.
in this case, it shifts the whole data by 32 bytes. (B0->D0)
I highly doubt the bug is in free mem. But if it is, you will probably need better proof than your current code. (The error could be in some other procedure, if "move" is used elsewhere.)
i know that usually it's your own fault when something is broken but i have seen errors in library, the windows-api or gnu-libc.
that's why i provided a link to a thread with some guy who also had segfaults in freemem (i couldn't spot the error in his code either)
Use heaptrc -gh
i have no idea what that is but i've set up valgrind. the output is attached. (wtf ? 0x161ab4c701047125 !!)
Add asserts. plenty of them.
naah, you're right there is hardly any debug-output in my code... i will have to think about doing that by default.
but so far, i haven't been able to reproduce the error reliably in smaller test-applications.
len := (used - i) * esize;
what if negative?
all types are cardinal. and
i must always be
<= used. i'm adding checks for big and absurd numbers anyway :-)
Just 3 floats, nothing else?
nothing else.
packed, even.
You are aware that if you use "move" on data, that contains ansistring or array, then you will be in for trouble too?
that is the downside of having highly-integrated strings; but i can assure you, i always copy strings in
arrays of char before getting nasty and make sure i pass the pointer to the first element to c-libraries, for instance.