Skip to content

Small bug in Memory Corruption Detected message #59

@hvassbotn

Description

@hvassbotn

Hi Pierre!

Long time - hope you are doing fine!

We have been a little slow in upgrading from FastMM4 to 5 - working on that now.

The new version seems to detect an overwrite that the old one didn't (could be random, though).

Specifically, I see during debugging that there is a single-byte overwrite in a freed block (with the $80808080 pattern) with a zero byte at offset 16.

The logic that detects and reports the offset(s) and size(s) of the post-free modifications is useful, but it seems to have a small bug.

Example:

---------------------------
Memory Corruption Detected
---------------------------
A memory block was modified after it was freed.

The block size is 36.

Modifications were detected at offsets (with lengths in brackets): 0(4), 16(1).

The allocation number is: 63285324

Current memory dump of 44 bytes starting at pointer address 6BE55D70:

E4 CE 41 00 80 80 80 80 80 80 80 80 80 80 80 80 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 02 A4 CF FF C3 1C 42 00

The problem is in the "Modifications were detected at offsets" line - the 16(1) part is correct, while the 0(4) is not.
The hex numbers at the front of the freed block is the address of the TClass reference to TFastMM_FreedObject class.

This exception to the $80808080 pattern is handled correctly by the overwrite detection code:

function CheckFreedDebugBlockFillPatternIntact(APDebugBlockHeader: PFastMM_DebugBlockHeader): Boolean;
...
    LFillPatternIntact := (PPointer(LPUserArea)^ = TFastMM_FreedObject)

But not by the offset/size reporting code:

procedure LogFreedDebugBlockFillPatternCorrupted(APDebugBlockHeader: PFastMM_DebugBlockHeader);
..
  LOffset := 0;
  LTokenValues[CEventLogTokenModifyAfterFreeDetail] := LPBufferPos;
  while LOffset < APDebugBlockHeader.UserSize do
  begin
    if LPUserArea[LOffset] <> CDebugFillByteFreedBlock then

It needs to make an exception for the first 4 bytes (8 in 64-bit mode) and compare with the TFastMM_FreedObject class address instead of the debug fill byte.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions