What can you do with the "Assember" tab in bug reports? Is it even useful?

[DP News-Robot]

We were contacted by a customer that claimed that his application worked fine until he added EurekaLog to it. Specifically, his application starts to raise an EAccessViolation exception with the following message:
Access violation at address 03DB472F in module 'Sample.exe'. Read of address 5653E4CC

The customer was kind enough to share the code mentioned in the call stack of the bug report:function TContosoEventCollection.FindEvent(const AValue: TContosoEvent): Integer;var X: Integer;begin Result := -1; if not Assigned(FEvents) then Exit; for X := 0 to FEvents.Count - 1 do // - crashes here begin if SameMethod(AValue, FEvents[X]) then begin Result := X; Break; end; end;end;Where FEvents is the TList field in the TContosoEventCollection class.

As a reminder: the TList class is implemented in the RTL like this:
type TList = class(TObject) private FList: TPointerList; FCount: Integer; // ... protected function Get(Index: Integer): Pointer; // returns FList[Index] // ... public property Items[Index: Integer]: Pointer read Get write Put; default; property Count: Integer read FCount write SetCount; // ... end; So, the code crashes while trying to read the FCount field of the TList class - which probably means that the TList object is not valid (in other words: trashed).

Well, the bug report can not be false-positive. So, what happenned? And why there is no access violation in the same application compiled without EurekaLog?

Quite often you would see message like this for memory errors:
Access violation at address ... in module '...'. Read of address DEADBEEF
Where the data address would match or be close to the DEADBEEF value - this is the debug marker that EurekaLog fills in the memory being deleted. In addition to DEADBEEF, you can also encounter other values: $CCCCCCCC, $FEEEFEEE, $FDFDFDFD, $FADEDEAD, $00009999. EurekaLog attempts to reserve at least one of them for debugging purposes and will use the first one for which the reservation succeeds. There may also be values close to them (i.e. debug marker + offset, e.g. DEADBE8F).

However, in this particular case: the data address is 5653E4CC - which does not match any known debugger marker. So, at the first glance it could be a valid data value.

Note that 5653E4CC is supposed to be an address of the TList's FCount field. Now, let's take a look at the "Assember" tab from EL's bug report:; Line=3297 - Offset=23; ---------------------03DB472F 8B7808 MOV EDI, [EAX+8] ;