Publishing PHP eclipse - part 12 pdf

Click on the first Environment tab to continue there are two Environment tabs, with the first tab for general settings and the second one for configuring environment variables: In the En

Working Directory is pre-filled, but not used This tab asks for interpreter parameters and file input parameters If you are doing PHP command-line scripting, you can add arguments here Click on the first Environment tab to continue (there are two Environment tabs, with the first tab for general settings and the second one for configuring environment variables):

In the Environment tab, the Remote Debug tab should appear first by default Make sure the Remote Debug and Open with DBGSession URL in internal Browser checkboxes are checked In Remote Sourcepath, specify the absolute path to the directory where your debug subject is located

Make sure there is a trailing slash at the end of your entry! Otherwise, the script location will not be recognized The debugger will appear to run, but it will not register any

variables and will not stop at breakpoints These are the most common debugger

problems reported by people on PHPEclipse forums, and the vast majority of the time, it

is because of this missing end slash

Remote debugging is the process of debugging a file on another server The server must have DBG installed and running In PHPEclipse debugging, we fool Eclipse by treating our local PHP/Apache instance as a remote server As of this writing, true remote debugging support in PHPEclipse is in its infant stages, but it can be done First, since the source code files are on a different server, you will need to mount the share locally In PHPEclipse, configure this mapping with the Mapped Path fields If there is a discrepancy between the operating system that you are

Chapter 5 Proceed with configuration of your local debugging environment by clicking on the Interpreter tab

In Mac OS X, as of PHPEclipse 1.1.8, a bug exists that prevents the entire label of

installed interpreters to appear Just click on the white box next to the Remote Debug tab

to pull up the Interpreter tab

Select the interpreter from the pull-down menu This is the same interpreter as you installed in the preferences earlier By allowing you to specify an interpreter, PHPEclipse allows you to experiment with different settings You can install different versions of PHP with different

compile parameters and test your application against them

At this point, you have finished building your debugging configuration Press the Apply button to save the configuration Click on the Debug button to begin the debugging process You can quickly access this configuration from the Debug icon in the Eclipse toolbar, which holds your

most recent configurations, or press Ctrl Command ( on a Mac) +F11, which automatically debugs

your last configuration You'll notice that when you debug, very often it's a repeating cycle of debug, quick edit, debug, quick edit You'll be thankful for having such quick access to your debugging configuration

If you are not in the Debug perspective, Eclipse will switch over to the Debug perspective and may ask you if you want to do this Click Yes to accept this change:

In the Debug perspective, Eclipse will pass your file to PHP and debugging will begin:

The process will run until the first breakpoint, which we set to line five, and then stop to await further orders We have several visual clues that let us know that this is happening

view, we see that the debugger has started, spawned a thread called

• In the Debug

main() (which is a residual effect from Java firing main() functions at launch), and the stack is in progress at line five

• In the editor, line five is highlighted, and a break arrow overlays the breakpoint on line five This highlight and break arrow tell us where the program is in the process

• In the Variables view, we see that this view is actually keeping track of variables and their values

If these three things happen, we know our debugger is working and PHPEclipse is configured correctly We can begin to debug our PHP applications

Chapter 5

Troubleshooting Tips

Correctly calibrating all of software packages that make up the debugger can be tricky There's a chance that the debugger will fail on the first run Usually, the debugging process will execute the script successfully, but the Variables view will be empty and the debugger will not stop at

breakpoints Unfortunately, Eclipse will not give out any further details except for Java exception errors in the Error Log view Follow these general tips to debug your debugger:

1 Make sure DBG is installed correctly If DBG is not even registering in your

phpinfo() page, then that needs to be fixed first No amount of Eclipse

configuration will correct the situation

2 If DBG is installed correctly, chances are your problem is in the PHPEclipse

configuration or php.ini/httpd.conf configuration Although not impossible, it is probably not an Eclipse error, nor, as long as it's reported as active in the phpinfo() page, a problem with DBG

3 Delete almost everything in your configuration directory except for the

config.ini file This directory holds your configuration settings for Eclipse It may have been corrupted When removed, Eclipse will automatically build everything

except your config.ini file, which is critical for Eclipse to startup The drawback to this method is that you will have to reconfigure a lot of your Eclipse preferences

4 Ask for help using all available resources For each of the open-source products you are configuring, there are several avenues of communication with developers and

other users Sure, there is overlap and conflict with each method A project may have

a BBS forum on the site, a BBS forum at SourceForge, a bug tracker at SourceForge,

a user mailing list, and a developer mailing list Check the archives of all of these

tools Very often, someone else will have run across the same problem and have

been able to fix the problem

5 If your debugger was working correctly and has suddenly stopped working, or the debugger works on some files and not others, beware of files that finish executing In PHPEclipse, the Debug view will not add a <terminated> signal to finished programs

as it will in Java applications Moreover, variables will set themselves correctly and then clear themselves from the Variables view! This means that the debugger may actually be working correctly and the script has either finished executing or

encountered a die() function In fact, in the example debug.php file, you'll see that each code block has a die() call at the end where we set our final breakpoint This is

to show us the final state of the application right before the execution ends If we

allowed the execution to finish, the application's variables would be wiped from the Variables view The best and most reliable way to see if your debugger is working correctly is whether it stops at a breakpoint

6 Use the Error Log view Eclipse has a very extensive and useful error logging feature

If the initial debugger run does not seem to work, it probably logged one or more

lines in the Error Log

Each exception will throw an error Of particular importance are the Export Log and Open Log buttons These features will collect all of the exceptions into either one text file or a window on screen If you feel that your error is a bug in either PHPEclipse or Eclipse, gather the information in this log and post it to the bug forum of the appropriate project Before you collect the exceptions, be sure to wipe out all existing entries in the Error Log view using the Delete Log button in the view's toolbar Then, when you recreate the error, the log you send with your report will be free of errors that are

unrelated to the bug

How to Use the Debugger

By clicking on the Debug button, we have started a debugging session Eclipse automatically switches us to the Debug perspective The application begins to execute, but it stops at line five because we told it to stop via a breakpoint Our program is now frozen until we do something to advance it Before we advance, let's take a look around the Debug perspective, explore the views, and see how things are frozen when our program has stopped

Debug View

The Debug view gives us a good idea of what the application is doing Mainly it tells us what function the application is executing at that particular breakpoint:

The Debug view organizes things from the broadest in scope to the most specific The first line, the Project takes its name from the name of the debugging configuration The Debug Target is the container for the threads that are running Underneath the Debug Target are the executing threads Since PHP is a single-threaded language, only one thread, the Main Thread, will ever execute at

one time This thread executes functions whose frames appear as a call stack The call stack, with

Chapter 5 Frames and call stacks may be new concepts to a web developer, so we'll briefly explain them When a function or method gets invoked, the system allocates a certain amount of memory to hold variables and do work for that function This memory is called a frame If a function calls another function, a second frame is created and stacked on top of the first frame This second frame needs

to execute and finish before it is removed from the stack The first frame then continues with its execution If more functions are called, they are placed at the top of the call stack

In PHPEclipse, the execution of the full script is treated as the main() function and is labeled as such If you've worked with C, C++, or Java, you'll know that a function named main() in a class holds special significance The system will automatically fire off main to execute a program

In our example, we see that the Eclipse has started work on the script and stopped at line five of the page This is shown in the first and only frame Frames are represented as three horizontal blue bars in the Debug view If we had called another function and stopped inside of it, we would see another set of frames on top of main Collectively, all of the frame lines underneath the main thread line represent the call stack of our script

By reporting on the call stack, the Debug view not only lets us know where we are in a script, but also how we got there We can trace back the calling functions and see what was called As we add loops and conditions into our application, seeing the breadcrumb trail is helpful to the

debugging process

The Debug view also lets us execute through the application using icons in the toolbar They are listed below:

Resume: Continues a program that has been stopped by either a breakpoint or Pause

command Execution will continue until either the next breakpoint or Pause command or end

of program

Pause: Stops a program's execution Paused programs act as if they were stopped by a

breakpoint You can examine variables and edit the file while a program is stopped

Terminate: Stops a debugging process

Disconnect: Not used in PHP debugging

Remove All Terminated Launches Removes all terminated processes from the Debug view Step Into: Moves to the next line of a stopped execution If the line calls a function, execution will continue and fall into the function

Step Over: Moves to the next line of a stopped execution If the line calls a function, line-by-line debugging will not enter the function Instead, it will execute the whole function, then pause

Step Return: If you're in a function, Step Return completes the execution of the function

without a break, returns to the caller frame, and then pauses execution

Drop to Frame: Not supported in PHPEclipse

Use Step Filters/Step Debug: Not supported in PHPEclipse

We'll see how these navigation features work later, when we start an actual debugging session

Variables View

With the Variables view, we can see the exact values of all variables at any breakpoint Many consider this to be one of the most valuable tools in an IDE No longer do you have to echo out variables to the screen You can evaluate them as the program runs, get far more information quickly, and alter the values if need be You even have more flexibility to evaluate more complex variables Object properties are listed in the Variables view There is no need to output properties one by one With arrays, all keys and values are reported You no longer have to loop through arrays in a foreach loop to examine values

In this example, we see that the variable $a was set to a value of 1 We also see a few environment variables that were set by the web server environment and reported back in DBG The breakpoint

is set to line five, which is where $b is set to a value of 2 Remember, breakpoints are honored

right before the line of code is executed If the breakpoint was set to line six, we would see $b = 2

in the Variables view

The Variables view offers several display options in its toolbar However, these are designed to

Chapter 5

Breakpoints View

The Breakpoints view lists all breakpoints in a workspace If you have a Java project with

breakpoints, they will also appear here Each entry gives you the file and line number:

This view's toolbar gives you some global management functions of your breakpoints:

Remove Selected Breakpoints: If you select a breakpoint in this view, clicking this icon will remove the breakpoint from the file

Remove All Breakpoints: Removes all breakpoints from files in your workspace

Show Breakpoints Supported by Selected Target: This should filter your Breakpoints view to only show breakpoints for whatever target you have in the Debug view This allows you to

move between currently running debug sessions and see only their breakpoints Unfortunately, this feature doesn't currently work with PHP breakpoints If you have a Java target selected, this icon will remove the PHP breakpoints, but for a PHP application, it does not know which files are PHP files, and removes all breakpoints from the view

Go to File For Breakpoint: From a selected breakpoint, clicking on this icon will open the file, if not open, and take you to the exact line number

Skip All Breakpoints: Not supported for PHP breakpoints

Expand All: Not supported for PHP breakpoints

Collapse All: Not supported for PHP breakpoints

Link with Debug View: Closely associates what you are doing to the Debug view

Add Java Exceptions: Not supported for PHP breakpoints

Console, Editor, Outline, and PHP Browser

All four views are part of this perspective and are helpful in the debugging process You can edit files on the fly in the middle of a debugging session and fix reported errors immediately The Outline gives you an overview of your file The PHP Browser will show you the requested file

The only difference is the editor The editor is linked directly with the debugging session You've already seen the breakpoints represented by blue dots in the editor During the debugging session, when the debugger encounters a breakpoint, a breakpoint flag will appear over the breakpoint and the line will be highlighted This is another way Eclipse shows you exactly where the execution has stopped

When you move through the file, the breakpoint flag and line highlighting will follow you They represent the stopping point of your application

Navigating Through a Debugging Session

If you haven't stopped the previous debugging session, do so now In the Debug view, click on the Terminate button in the toolbar The Debug target line will now have <terminated> at the beginning and the icon will lose its motion arrows, indicating that the process has stopped Click

on this motionless Debug target line to highlight it and click on Remove All Terminated Launches

to remove it from the view

Let us try a slightly more complicated debugging exercise Now that we have a familiarity with the Debug perspective and what we're looking at, let's try to navigate through a session Debugging in PHPEclipse follows industry-common practices and works very similarly to debugging in other IDEs The terms you encounter here can be carried over to other languages and other tools First, replace the code in debug.php with this code This code sets some variables, and calls a local function The local function returns a value that is used by the calling method

<?php

$catID = 1;

$catName = "Crinkle";

$catID = 42;

$hb = getHairball("Gack");

echo $catName " presents a hairball!\r" $hb;

function getHairball($sound)

{

Chapter 5

$hairball = str_repeat($sound, $size);

return $hairball;

}

die("End of Script");

?>

Set a breakpoint at line four, where $catName is set to 'Crinkle'

Fire off the debug session again by going to the Run | Debug History | Debug Test menu option You can also find the Debug History function in the toolbar of Eclipse

The debugger will start and stop at line four The only line that has been executed is line three, where we set $catID to 1 Confirm the value of $catID in the Variables view

Click on the Step Into button to advance execution to the next line Now, line four has completely executed and $catName has been set Confirm both the $catID and $catName variables values in the Variables view

Click on Step Into again Line five has executed The debugger will skip line six, a blank line, and stop at line seven The value of $catID has changed Again, confirm this in the Variables view

$catID should have shown up previously as 1, but now line five should have changed it to 42 This is how your Variables view should look like right now:

Clicking on the variable will give us the entire value of the variable in the lower value pane This pane is useful for values that are extraordinarily long

Click on Step Into again This time, Step Into truly steps into a function The debugger will stop at the first line of the function A second frame is created in the Debug view's call stack The frame is named after the called function The Variables view only shows variables that are in scope When the debugger enters a function, the Variables view shows the local variables of the function that it

is executing However, Eclipse by has no means forgotten the variables in the script that called the function At any time, you can see the parent's stack variable values by clicking on the preceding call stack in the Debug view The Variables view will change to show only the values for that particular stack You can move up the stacks indefinitely with this method to see all variable values To return to the function's variables, click on the function's call stack in the Debug view: