Forum > General
really sad sigsegv in freemem. perhaps even tragic.
Martin_fr:
I am not sure about cmem.
valgrind:
--- Code: ---Invalid read of size 16
==25055== Address 0xd4a75d0 is 5,088 bytes inside a block of size 5,100 alloc'd
--- End code ---
This is normal. When there are 12 bytes needed, it may be more efficient to read 16.
--- Code: --- Address 0x161ab4c701047125 is not stack'd, malloc'd or (recently) free'd
--- End code ---
And that is not good.
So at
enginememory.pas:384
you probably use a pointer that is dangling or uninitialized.
Find out what variable it is.
Then (if it is NOT a local var) you can set a watchpoint to break whenever it changes.
if it is a member of an object, ensure that the object has not been destroyed
-- edit /Correction
--- Code: ---procedure waitfree_fixed(pmc: pmemchunk_fixed; poc: poschunk);
begin
{$ifdef FPC_HAS_FEATURE_THREADING}
entercriticalsection(heap_lock);
{$endif}
pmc^.next_fixed := poc^.freelists^.waitfixed;
poc^.freelists^.waitfixed := pmc;
{$ifdef FPC_HAS_FEATURE_THREADING}
leavecriticalsection(heap_lock);
{$endif}
end;
--- End code ---
Probably while folowing the linked list of mem chunks. So something (your code) has overriden a part of the fpc mem managment structure.
yogo1212:
nice clues!
sadly, i have already spent too much time with this problem for today :-p
i'll resume the witch-hunt tomorrow
EDIT:
one more thing before i go:
the attached file is a screenshot of my debug-view.
i'm way to tired..
Martin_fr:
Use watchpoints (data break points)
http://wiki.lazarus.freepascal.org/IDE_Window:Breakpoints
Always define them as global scope. write access only
Use one to determine when the pointer in Data changes.
use one to determine, if and when the last byte after data changes. data[(capacity+1)*esize]
When data changes, you need to delete, and recreate the 2nd watchpoint
yogo1212:
OK
I found it!
in some earlier code i had used three arrays and i wrote over the boundaries of the second.
that left the control-structure of the third array in a broken state and 10 or so allocations later everything brakes.
the only reason i was able to find that was the git log :-D
Navigation
[0] Message Index
[*] Previous page