Re: [DUG] IsClass access violation

Jolyon Smith Wed, 13 Nov 2013 19:41:33 -0800

It is perfectly possible for self to be NIL (the "Free" method relies on this fact). If SetModified is not virtual then you can happily call it with a NIL reference - it will only blow up when the code attempts to access any member data.

i.e. if self were NIL then the AV would occur on the FModified := Modify line.

Since you are not getting an AV on that line then the one thing you can be sure of is that self is not NIL. :)

The read address in that access violation is very odd. If the object were previously valid but destroyed then I would expect a more "random" looking address. It also seems a curiously high address.

Another possibility is that the SetModified() method has been called using a hard-typecast on some other value, not even necessarily a valid object reference. If so, then the procedure will be running in some sort of no-mans land where setting the memory that it thinks is "fModified" is acceptable but will do unpredictable damage with the wheels only coming off when calling up the class hierarchy to check the class type.

e.g. in a form event: TCustomDetails(self).SetModified(FALSE) will compile and run but the line that sets fModified := Modify will actually overwrite some private member data of the TForm (assuming that TCustomDetails is not a form class) and if it doesn't blow up in your face right away something almost certainly will go "bang" at some point later.

If that is what's going on, the fact that it is blowing up when attempting to call the IsClass method suggests that whatever has been type cast isn't even an object reference at all.

It's a puzzle, that's for sure.

Are there any other potential factors ? Runtime packages ? Threads ?

fwiw - an ancestor class referencing a sub-class is unusual and often reflects a shortcoming in the OO model, but I wouldn't go so far as Todd as saying that it should NEVER be done. Without reviewing your class hierarchy it's impossible to say for sure. There may be good reasons for it and it is unlikely to be directly related to your problem in any case (he said, offering up a hostage to fortune!). :)

Ross Levis

Thu, 14 Nov 2013 15:51

I’ve got a strange error occurring for just one user where this procedure is failing...

procedure TCustomDetails.SetModified(Modify: Boolean);
begin
FModified := Modify;
if Modify then
begin
    if Self is TCategoryDetails then MainForm.CategoryChanged := True
    else MainForm.SpotChanged := True;
end;
end;

TCategoryDetails and another class is inherited from TCustomDetails.

Access violation at address 004047DC in module 'SPLCreator.exe'. Read of address FFFFFFDF.
main thread ($87c):
004047dc SPLCreator.exe System                TObject.InheritsFrom
00404742 SPLCreator.exe System                @IsClass
005dc6a6 SPLCreator.exe SPMain      3831   +4 TCustomDetails.SetModified

Would this happen if Self was nil or invalid? I don’t see how that could happen but just wondering how this can happen.

Cheers,
Ross.
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with 
Subject: unsubscribe

Re: [DUG] IsClass access violation

Reply via email to