The most annoying type of bug - one which only occurs on one computer. There is always the possibility that it is a problem with that particular machine, bad memory or some a corrupt DLL/malware, etc. Most of the time when we have run into something like this it turns out to be our code still, but the thought that it might not be and you're going on a wild goose chase is frustrating!
From: [email protected] [mailto:[email protected]] On Behalf Of Ross Levis Sent: Thursday, 14 November 2013 9:59 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] IsClass access violation This code is working in about 1100 installations for over 12 months, and executed around 1000 times a day at each installation, and the class referencing is working correctly to determine if it is a TCategoryDetails object or not. Whether it should or shouldn't be done is another matter. I don't see any logical reason not to. Only 1 user is having an occasional problem at the same line of code, twice in the last 2 weeks. I can't find a situation where the object has been freed and my object storage not updated, but I suspect it must have been somehow. I'll have a closer look. Cheers, Ross. From: [email protected] [mailto:[email protected]] On Behalf Of Jolyon Smith Sent: Thursday, 14 November 2013 4:39 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] IsClass access violation 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!). :) <mailto:[email protected]> 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
<<image001.jpg>>
_______________________________________________ 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
