[ Pobierz całość w formacie PDF ]
.Now let s look at several more advanced debugging tasks.Locating the Source of Access ViolationsEarlier in this chapter we examined some basic techniques for locating bugs.Accessviolations (AVs) are sometimes more difficult to locate than general program bugs.Other application errors are similar to AVs, and the techniques described here applyto those also.Access violations can be caused by access to memory that is not within the applica-tion s memory space.If at all possible, you should use CodeGuard to check yourapplication at runtime.CodeGuard can detect many errors that would normallyresult in an AV and pinpoint the exact line of source code that produced the error.Ifyou can t use CodeGuard for your application, or CodeGuard does not detect theerror that caused the AV, there are other things you can do to track down the error.When an AV occurs, a dialog box is presented with the message Access violation ataddress YYYYYYYY.Read of address ZZZZZZZZ.Application errors can present a differ-ent message, such as The instruction at 0xYYYYYYYY referenced memory at 0xZZZZZZZZ.In these cases, the YYYYYYYY address is the machine code that caused the error, andaddress ZZZZZZZZ is the invalid memory address that it attempted to access.It is possible to locate where some access violations occurred by implementing aglobal exception handler.Alternatively, you can run your application withinC++Builder and wait for the AV to occur.If you can t reproduce the AV when running within C++Builder, simply pause yourapplication using Run, Pause or by setting and hitting a breakpoint, open the CPUview and select Goto Address from the context menu.This is not foolproof, but itoften works.Enter the code address given in the AV dialog box in hexadecimal as0xYYYYYYYY.The code around this address might give you some clue as to where inyour source code the AV occurred, particularly if the application was compiled withdebug information.When the memory address ZZZZZZZZ is close to zero, for instance 00000089, the causeis often an uninitialized pointer that has been accessed.The following code wouldproduce an AV with this memory address because the MyButton object was nevercreated with new. 04 0672324806 CH02 12/12/02 2:42 PM Page 7272 CHAPTER 2 C++Builder Projects and More on the IDETButton *MyButton;MyButton->Height = 10;What is actually happening is that when MyButton is declared it is initialized with avalue of zero.The address 00000089 is actually the address of the Height propertywithin the TButton object if it were located at address zero.As a general rule, you should explicitly initialize pointers to some recognizable valuebefore the memory or object is allocated, and back to that value once it has beenfreed.If you get an AV that lists this value, you know an uninitialized pointercaused it.Sometimes an AV can occur in a multithreaded application in which concurrentaccess to objects and data is not controlled.These can be very difficult to find.Usedata breakpoints and the outputting debug information techniques described earlierin this chapter if you suspect concurrency problems.Attaching to a Running ProcessWhen a process is running outside the C++Builder IDE, you can still debug it usingthe integrated debugger by attaching to it while it is running.This feature can behandy during testing.When you detect the occurrence of a bug in the application,you can attach to the application process and track down the bug.The only draw-back is that Windows does not provide a method for detaching from the processwithout terminating it.To attach to a running process, select Run, Attach to Process.The Attach To Processwindow is displayed with a list of running processes on the local machine.Select theappropriate process from the list and click the Attach button.The C++Builder debug-ger will then attach to the process.The process will be paused, and the CPU viewwill be displayed at the current execution point.You can step through the code, setbreakpoints, load the source code, if available, using View Source from the contextmenu, inspect values, and so on.Attach To Process is even more useful for remote debugging.In the Attach To Processwindow, you can view and attach to processes on another machine that is runningthe remote debug server.This is covered in the Using Remote Debugging section,later in this chapter.In the window you can also view system processes by checking Show SystemProcesses.You should be very careful about attaching to any old process; you can causeWindows to crash or hang by attaching to system processes.Stick to attaching toyour own processes [ Pobierz całość w formacie PDF ]