![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Debugging a standard application
Now that you understand how to use EPIC to move through a project and run an application, it is time to jump into the debugging of a standard application.
All you have to do is change the configuration of a standard Run environment into a debugging configuration. Eclipse then provides a debugging perspective that includes support for standard debugging tools like breakpoints and the ability to watch variables during execution.
Configuring an application for debugging
To configure a script in your project to be executed:
- Choose Debug from the Run menu. You'll be presented with the dialog shown in Figure 12.
Figure 12. Debug configurations
- Select the Perl Local item and configure the perspectives to be used when debugging a local Perl script (not remote or CGI). Your perspective will automatically switch to the perspective shown here when you run the script. Since you are configuring for debugging, choose the Eclipse Debug perspective.
- You can, optionally, create a new configuration, or use the existing configuration. To create a new configuration, select Perl Local from the list of configurations on the left of this dialog box and choose New. You'll be presented with a new Run configuration just like Figure 13.
Figure 13. Adding a new debug configuration
- Configure the name of the project and script you want to execute. Note that you can also add any command-line options to your script. Remember to add a configuration name, and be aware that this configuration is specific to this script in this project.
- Click Apply, then Close to save the configuration.
Once your configuration is active, your script is ready to debug. Click Debug to start the debugging process.
The Eclipse debugging perspective is shared and used by most debugging systems in Eclipse, including when debugging C/C++ and Java applications. You can see a sample of the debug perspective in Figure 14.
Figure 14. Debug perspective
The debug perspective is made up of a number of default views, including:
- Debug view
- This shows running scripts, including multiple threads in a single script. You can see a close-up in Figure 15. Here, it's showing a running script (the Main Thread) and the Perl Debugger thread (used as an interface for running the script). Note that the current line of the script on which execution has been paused is also shown. If you select this item from the view, the corresponding line from your source code will be shown.
- Variables view
- This can be used to show the values of variables, and it has an output similar to the information shown by the
Dumper()function examined in this tutorial when looking at traditional debugging methods. You'll take a closer look at how to configure variables to be watched shortly. - Breakpoints view
- This shows the configured breakpoints for the application being debugged. Configuring breakpoints will be covered in more detail shortly.
The remainder of the views should already be familiar to you, such as the editor views, project outline, and console views.
Once you have started to debug your application, you will want to start stepping through the lines of your code and monitoring the output. The debugger automatically stops at the first line of executable code (after any modules have been imported).
Stepping through a debugged application
Stepping through an application being debugged enables you to monitor the execution of the script on a line-by-line or function-by-function call basis. By stepping through, you can trace the execution through function calls, test statements, and so on; and monitor the value of variables during the execution of the code.
Eclipse supports five step modes, although in most situations, only the first three are supported by the EPIC plug-in. Step modes can be selected by using the step buttons on the toolbar (the last five buttons on the right of the toolbar panel):
- Step Into -- This steps into a function, loop, or other statement. If the function is available, the debugger will show the source code and allow you to step through the source code.
- Step Over -- This steps over a statement to the next statement in the code.
- Step Return -- If you have stepped into a function, then step return will execute the code up to and including the return statement for that function.
You can also restart execution until the next configured breakpoint or the end of the script -- whichever comes first -- by clicking the "play" button (just your VCR play button), and pause execution by using the VCR-like pause button, and stop execution altogether by pressing the stop button.
If you stop an execution and want to relaunch a debug process on the same script, choose Relaunch from the menu when you right-click on the process.
Breakpoints are lines in the code where you want execution to pause or stop during the execution of the script. They do exactly what you expect: break execution at that point.
To configure breakpoints, right-click in the border next to the line your source code where you want to add a breakpoint.
You'll be prompted with a menu that will allow you to add a breakpoint at that location in your code. You may find it useful to enable line numbers (also available through the same menu).
When a breakpoint has been added, you will get a breakpoint icon next to the line, as can be seen in Figure 15. The breakpoint icon is shown next to line 6 of your source code.
Figure 15. Code with breakpoints
You can also access a list of configured breakpoints by using the Breakpoints view (Figure 16) that lists the type, file and line number of all the configured breakpoints in a project.
Figure 16. Breakpoint view
To remove a project, either right-click on the line from the source code again and choose Remove Breakpoint or select it from the list of breakpoints, right-click, and remove it that way. You can also enable and disable breakpoints, which can be more convenient if you are debugging the same code and want to monitor the same locations, but not necessarily at the same time.
Once you select a running thread, a list of all of the variables in the current scope will be shown in the Variables view. You can see a sample of the Variables view in Figure 17.
Figure 17. Debugger variables
Unlike most debuggers that show variables only when you have specifically added them to a list of variables to be monitored, the EPIC debugger automatically shows all variables within the current scope. As you can see, the full details of the variable are made available, and you can use a tree-like interface to interrogate the values of complex structures like nested arrays and hashes from the script. Note that local variables have an icon with an "L" embedded; all other variables use the standard variable icon.
Variables that have changed since the last execution step are highlighted in red. This makes it easy to find changed variables while stepping through the application.
In addition to the variables defined in your script (both global and local to the current block), the variable view will also, by default, show some global variables that you have implied the use of in your script. For example, it will show the values of the special STDIN, STDOUT, and STDERR variables.
You can also optionally display internal Perl variables (such as $$, %ENV, etc.). Click on the View menu and choose Show Perl Internal Variables. A sample of the Variable view with this enabled is shown in Figure 18.
Figure 18. Showing standard internal variables
Remember that the Variable view shows only the variables within the current scope or global variables. It does not show variables that are not available in the current scope (function, loop, block, or even module or package).
