A few notes on tracking down a use-after free related issue involving interfaces.
The crash message is like this:
Project UseAfterFreeWithInterface.exe raised exception class $C0000005 with message 'access violation at 0x004106c0: read of address 0x80808088'.
Two things here:
- the is the hexadecimal value of
STATUS_ACCESS_VIOLATION, which is sort of mentioned in [WayBack] Delphi 2009: EExternalException Class, but not documented in any more recent Delphi versions. It is in the code for the units System, System.SysUtils and Winapi.Windows (see below).
The value is not well documented on the Microsoft documentation site either: you sort of have to connect the dots between site:docs.microsoft.com “0xC0000005” – Google Search and [WayBack] site:docs.microsoft.com “STATUS_ACCESS_VIOLATION” – Google Search to find for instance these two:
- The
0x80808088comes from the [WayBack]FastMM4.pasDebugFillPatternvalue$80808080which is used to overwrite freed memory. Not all versions of FastMM4.pas have that value near the DebugFillPattern in the code, so I raised an issue for that: [WayBack] Document default 32-bit values of `DebugFillPattern` and `DebugReservedAddress` · Issue #67 · pleriche/FastMM4 · GitHub
The relation between
$80808088and$80808080(a difference of just$00000008) comes clear when you look at theSystem._IntClearmethod disassembly below. - If you use EurekaLog instead of FastMM4, then you addresses will be patterns based on
$DEADBEEF, see these links on why:
An important note first
Basically any memory value in an exception starting with
$8080and sometimes even$80should raise suspicion: it usually means a use-after-free case.
You see these errors with FastMM and not with the memory manager as [WayBack] delphi • View topic • Problem with FastMM and D7 explains:







