Although you can use PHP to create command-line scripts for tasks such as system management and traditional data processing, programming languages have a major impact on the performance of WEB applications. Each PHP application resides on the server during use, and the PHP application handles incoming requests through proxies, such as Apache. For each request, a typical PHP Web application will get a Web page or XML data structure after a short run.
Assuming that after a simple run, a layered WEB application-including clients, networks, HTTP servers, application code, and the underlying database-will make it difficult to isolate errors in the PHP code. Even assuming that all layers are working correctly except for the PHP code, it can be difficult to track errors in your PHP code, especially if your application uses more classes.
PHP statement Echo and Function Var_dump (), Debug_zval_dump (), and Print_r () are common and popular debugging aids that can help solve a variety of problems. However, these statements-even the more robust tools, such as PEAR Log package--, are forensics tools that must be speculated on outside the context to generate evidence.
In a way, it is a reckless practice to debug by inference. Collect and filter the data to try to infer the problems that occur. If important information is missing, you must test the code again, repeat the steps, and then start the study again. A more efficient approach is to probe applications while the program is running. You can categorize the request parameters, filter the procedure call stack, and query for any required variables or objects. You can temporarily break the application and you can receive an alert when the variable changes value. In some cases, you can interactively ask if ... What's going to happen? "The problem actually affects the variable.
Special applications called debuggers support this "real time" or interactive check. The debugger may start and connect to a process to control the process and monitor its memory. Or, in the case of an interpreted language, the debugger can interpret the code directly. A typical modern graphical debugger can index and browse code to easily display complex data structures in a form that conforms to human reading habits, while displaying program state, such as call stacks, intermediate outputs, and values for all variables. For example, the debugger typically classifies and describes the properties and methods of a class.
In this and the next article, I'll introduce the tools that will make PHP easier to debug. Next time, I'll focus on interactive debugging and Zend debugger--a robust debugger specifically for PHP-and explore the many features it offers. (Zend Debugger is a commercial product and is part of the Zend PHP integrated Development Environment (IDE).) I'm also going to introduce an open source PHP debugger so you don't want to spend your money on beer instead of code. However, this article will mainly introduce how to better evidence.
Similar to crime scene investigation, just more annoying.
When the code goes wrong, fails to generate a desired result, or crashes completely, you need to answer four W questions: where, what, why, and when:
The "where" is the file and line number where the application was last run.
"What" is a code of error--for example, a suspect.
"Why" is the essence of error. It may be a logical error and/or an error caused by interacting with the operating system, or both.
The "when" is the context in which the error occurred. What happened before the program terminated? As in all criminal acts, if you can gather enough clues, then clues can help you find the culprit.
A forensics tool Xdebug (the tool used in the previous article to analyze PHP application performance), as shown in the name, provides several features that illustrate program state and is a valuable research tool that should be added to the instruction system (see Resources). After installation, XDEBUG will block infinite recursion (ostensibly), fix error messages about stack traces and function tracking, and monitor memory allocations, and provide additional functionality. Xdebug also includes a set of functions that you can add to your code for Run-time error diagnosis.
For example, the following code will use some xdebug_ ... () step to test the callee () function to output the exact location of the calling program, including the filename, line number, and name of the calling function.
Listing 1. To test the callee () function
function callee ($a) {
Echo sprintf ("callee () called @%s:%s from%s",
Xdebug_call_file (),
Xdebug_call_line (),
Xdebug_call_function ()
);
}
$result = callee ("arg");
?>
This code will generate:
Callee () called @/var/www/catalog/xd.php:10 from {main}
Back to the top of the page build and install Xdebug
Xdebug can be easily built from source code in the UNIX® class operating system, including Mac OS X. If you are using PHP on microsoft®windows®, you can download the latest PHP version of the binary Xdebug module from the Xdebug Web site (see Resources).
Let's build and install Xdebug for Debian "Sarge" linux® and PHP v4.3.10-19. At the time of this writing, the latest version of Xdebug is V2.0.0RC4, published on May 17, 2007. To continue this article, you must have the Phpize and Php-config utilities, and you must be able to edit the system's php.ini configuration file (if there are no utilities, visit php.net to get the source code and instructions for how to build PHP from scratch). Please perform the following steps:
Download Xdebug tarball (A. Tar archive that is compressed with gzip). The wget command can help you do this easily: $ wget http://www.xdebug.org/files/xdebug-2.0.0RC4.tgz
Unzip the tarball and switch to the source code directory: $ tar xzf xdebug-2.0.0rc4.tgz
$ CD XDEBUG-2.0.0RC4
Run phpize to prepare the Xdebug code that applies to your PHP version: $ phpize
Configuring for:
PHP Api version:20020918
Zend Module Api no:20020429
Zend Extension Api no:20021010
The output of phpize is a script--typically called a configuration--to adjust the rest of the build process.
Run configuration script: $./configure
Checking build system Type ... I686-pc-linux-gnu
Checking host system Type ... I686-pc-linux-gnu
Checking for gcc ... gcc
Checking for C compiler default output file name ... a.out
Checking whether the C compiler works ... yes
Checking whether we are cross compiling ... no
Checking for suffix of executables ...
Checking for suffix of object files ... o
...
Checking whether stripping libraries is possible ... yes
Appending configuration Tag "F77" to Libtool
Configure:creating./config.status
Config.status:creating config.h
Build Xdebug extensions by running make: $ make
/bin/sh/home/strike/tmp/xdebug-2.0.0rc4/libtool
--mode=compile gcc-i.
-i/home/strike/tmp/xdebug-2.0.0rc4-dphp_atom_inc
-i/home/strike/tmp/xdebug-2.0.0rc4/include
-i/home/strike/tmp/xdebug-2.0.0rc4/main
-i/home/strike/tmp/xdebug-2.0.0rc4
-i/usr/include/php4-i/usr/include/php4/main
-i/usr/include/php4/zend-i/usr/include/php4/tsrm
-dhave_config_h-g-o0-c
/home/strike/tmp/xdebug-2.0.0rc4/xdebug.c-o
Xdebug.lo mkdir. Libs
...
Build complete.
(It is safe to ignore warnings about Tempnam and Tmpnam).
Use make to generate the Xdebug extension xdebug.so.
Install this extension: $ sudo make install
Installing Shared extensions:/usr/lib/php4/20020429/
Before continuing, use the mouse to select and copy the directory displayed by the previous command. This path is critical for the last-step configuration extension.
Open the php.ini file in your favorite text editor, and then add the following code: zend_extension =/usr/lib/php4/20020429/xdebug.so
Xdebug.profiler_enable = Off
Xdebug.default_enable = On
The first row loads the Xdebug extension, and the second line disables the Xdebug parser feature (just for simplicity), while the third line enables extended debugging.
To verify that the Xdebug extension is installed and enabled, restart the Web server, and then create a simple one-line PHP application in code. If you point the browser to a file-such as http://localhost/phpinfo.php--and scroll down-you should see something like Figure 1.
Figure 1. Verify that the Xdebug extension is installed and running
Note: If you do not see the Xdebug part in the output of Phpinfo (), the Xdebug mount fails. The Apache error log lists the reasons. Common errors include zend_extension path errors or conflicts with other extensions. For example, if you need to use XCache and Xdebug, be sure to load the XCache first. However, because Xdebug is suitable for use at development time and assumes that the xdebug.so path is correct, you need to disable other extensions and try again. You can then re-enable the extension to perform other tests, such as the effect of caching. Xdebug site also has some other troubleshooting skills.