Monday, January 2, 2006

What are general debugging techniques for AVs?

When you receive the dreaded Access Violation, the first thing to understand is what the computer is actually telling you. An AV is the Windows' description of an exception that was raised by the hardware itself. The hardware knows which processes should be accessing what memory and has detected a rogue process trying to read or write to memory that it does not own. It then tells the operating system which handles the error in various ways depending on the O/S and the context of the error.

So when you see the error with those cryptic long hex addresses, what the computer is telling you is that the instruction at the address of the named program tried to reference memory that it did not have rights to. That is all it means. It does not mean that the code at that address is necessarily the culprit, although it may. It does not mean that the named program is faulty, although it may. It simply means the hardware determined that the named program at that moment in time was not operating properly.

Another thing to keep in mind is that just because you do not have AVs does not mean you do not have a problem with memory access. It just means the hardware has not detected it. You may very well have problems but they do not extend past memory you do have rights to so the hardware does not detect it. Symptoms of this are when variables change value for no apparent reason and "correctly" running code suddenly starts AVing for no apparent reason.

Remember too, different operating systems map memory differently. There may be a problem on one platform that is not manifest on others. Many times people develop a program in Windows X and have no problems. They then run it in Windows Y, get AVs and blame the O/S. It cannot be their program since it runs just fine on the other system. No. They just have not found the problem on the other system. This is actually not unique to Pascal programs or the Windows O/S. For example, the same principle holds true for C programs in UNIX. Many times code that has run flawlessly for years on one version falls over when it is compiled on another platform.

Because of the inexact nature of AV reporting, they can be very trying to track down. Within the Delphi environment there are a couple common bugs to look for:
  1. Is it during object creation?
  2. Is it during object destruction?
  3. Is it when accessing a pointer (including a PChar) or object?
  4. Is it when accessing an array?
Post a Comment