Typical exception addresses

Does anybody have good links that specify what the read of address XXXXXXXX portion of an exception is referring to?

I know there are some common ones. For example I believe that "Read of address FFFFFFFF" referrers to an invalid (nil) pointer if I am correct?
LVL 6
rbohacAsked:
Who is Participating?
 
MadshiConnect With a Mentor Commented:
Access violations normally contain 2 addresses. E.g. "access violation at address 1111. Read of address 2222". An access violation always means that your code tried to either read or write a memory page for which it has no access right. The first address tells you at which code location the access violation occurred. The second address sais which address your code tried to read or write. If the first and second addresses are identical that means that somehow your process jumped to a code location which is not readable. Look at this code:

var proc : TProcedure;
begin
  proc := nil;
  proc;

This will jump to address 0. As a result you will get the message "access violation at address 0. Read of address 0" or something like that. As I said, that means that your code jumped to a non-readable code location.

If the 2 addresses are different, then the access violation can have 2 reasons:

(1) Either the code address is bogus. Maybe your code jumped to a random code location.
(2) Or the read/write address is wrong. Maybe you try to read from an object, which was already freed.

To find out which is the case, you should check whether the code location (the first address) makes sense. If you're using madExcept, check out what the very first callstack item sais. If madExcept was able to find a function name for the code location (the first address) then probably (2) is the case. Otherwise (1) sounds more probable.

Access violations are the most ugly kind of exceptions and sometimes very hard to track down. If you fight with such exceptions, you should make sure that you replace all "someObject.Free" calls and all "FreeMem" calls with "FreeAndNil" calls. Also you should "nil" all variables after having called "Dispose" on them. As a result you might get more exceptions than before. But they will be like "Access violation at address xxxxxxx. Read of address 0". That means, the code location is probably correct, but you can see that it tried to dereference a "nil" object. madExcept will in that case show you directly which code crashed. Then you know which object/variable was unexpectedly "nil".
0
 
shaneholmesCommented:
It means that somewhere in your application, the VCL expected a valid pointer that isn't there anymore.
A common mistake that causes this is for example to
free a class instance more than once.
Another one is to manually release a form with 'FREE' when it was created by application.createform instead of Tform.create.
(In that case the application tries tofree the form again.
Check for manually released classes and check of they are freed more than once.
There can be a whole host of other causes but freeing a class more than once is the most common

Try this:

http://help.madshi.net/madExcept.htm

Shane

0
 
Lee_NoverCommented:
>> Another one is to manually release a form with 'FREE' when it was created by application.createform instead of Tform.create.
>> (In that case the application tries tofree the form again)

never saw this and it also isn't logical
a TComponent.Destroy notifies it's owner (in this case the Application) to remove it from the Components List
so how could the Application try to free a form that isn't in the Components List ?
0
 
rbohacAuthor Commented:
This was actually taken from madExcept. I understand the problem with the example I gave, but what I am looking for is other common errors. I was just wondering if there was something out there to aid with troubleshooting.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.