[DUG] IsClass access violation

[Jolyon Smith]

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 <mailto:ross at stationplaylist.com>
> 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: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
> with Subject: unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20131114/a052cd1d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://listserver.123.net.nz/pipermail/delphi/attachments/20131114/a052cd1d/attachment-0001.jpg