Tracking Down The Location of some avs
Track access to conflict AVS
This is easily identified if an AV is derived from an attribute (or method) attempting to access the class without initialization. On the other hand, if there is a lot of code, or the AV appears in multiple repetition cyclicers, it is quite difficult. Fortunately, (C Builder or outside) AV error message is displayed through the window. This helps identify errors due to illegal memory access. There are two things that must be kept in mind in mind: a) Don't scare you on the sixteen. b) Don't be afraid of the CPU window.
Consider the following code segment:
Tedit * editbox;
Editbox-> AutoSelect = FALSE;
This seems correct in grammar, in fact, the compiler will not report an error. Of course, the problem will expose when running. When running, you will get an error similar to "Access Viological AT (SomeAddress) in module vcl40.bpl. Read of address 000001f4." Try it.
what happened? OK, an object (Object) in the memory is very similar to the array. We'd better look at an array first. Consider the following code segment:
Int Myintegerarray [10];
Myintegerarray [0] = 6;
Myintegerarray [1] = 88
When we assign a value for the first position of MyintegeraRray [0], we actually set the memory location assigned by the compiler "Myintegerarray" to 0. Then move 6 to this memory location. Then the good compiler is allocated (reserved) The 9 INT size memory cells are ready to use it. So, when we assign a value 88 to Myintegerarray [1], we actually add the sizeOf (int) size in the location specified by Myintegerarray, and then fill 88. General, MyintegeraRray [n] can be considered MyintegeraRray (N * SizeOf (int)).
Entity (n * sizeof (int)) can (also) is imagined as a "offset".
What is the relationship with access conflict access ViOLATIONS?
The value of the front 'read of address' is offset from EditBox! Review the previous code snippet, good C Builder automatically initials Editbox to 0. When we try to access an attribute of EditBox, we actually add the offset value of the attribute (like the array as the previous) base pointer. But at this time, the value of the base pointer is 0! Since the offset of 00000000 AutoSelect (000001F4) is not an absolute memory address that the user allows access, we get an av.
How do we solve the av?
The first is also the most important, the previous introduction should increase your comprehensive understanding of various AVs. Second, the information provided in the AV message box can be used to isolate advanced language code that caused problems. Here is the detailed steps:
1.) Record the address of the AV. It is the '(someAddress)' mentioned earlier.
2.) Set the breakpoint (main form main form) at the first constructor running.
3.) Running the project.
4.) Press CTRL-ALT-C when the program is locked at the breakpoint and pops up the CPU window.
5.) Right click on the area of the assembly code in the upper left corner.
6.) Select 'Goto Address'7 from the pop-up menu.) Fill in' 0x (someaddress) 'and enter the' Enter Address to Position to 'in the pop-up window.
Use the previous TEDIT example you will see:
VCL40. @ stdctrls @ tcustomedit @ set / ze $ qqr4bool
It is very simple. We are in the VCL40 module and try to access TCUSTOMEDIT SETAUTOSIZE. Now you can start isolating the culprit caused by AV. Just exclude in the TCUStomedit object. Since the access is AutoSize property. When you find these, you can basically affirm that you have found the advanced code that caused AV!
Now grab this dirty AVS now!
Cker@sina.com
