Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. read more at WikiPedia

  • Debugger are full-featured PHP debugger engine. They are interactive tools that allows
    you to debug PHP scripts locally or remotely, from an IDE or from the console. There is 3
    debugger on the market, XDEBUG (open source) , ZEND (closed source), DBG (commercial
    but source code available) by luck all are free :-)

    I recommend you to develop with Eclipse PDT: The Eclipse Foundation has released the 1.0
    of the Eclipse PHP Development Tools (PDT) project. Eclipse PDT is a set of tools and
    frameworks that enhance the productivity of developers using PHP, a popular, general-purpose
    dynamic language that is especially suited for development of web applications and web services.

    I have prepared a HowTo also for eclipse PDT, but it is still not ready for prime time.


  • Native debugger.
  • Debug locally or remotely
  • JIT. When enabled it can start debugging Just In Time when an error happens.
  • Supports back-trace, e.g. displays a list of all procedures with their local variables,
  • Step-in, step-out, step-over, run to cursor, change execution point withing current scope...), evaluate any valid php expression(s) or inspect arrays, classes and simple variables, modify their values on the fly and even create any new variables.
  • Supports conditional breakpoints and even global ones
  • Allows to change execution point
  • has embedded profiler,
  • Allows multiple debugger processes running simultaneously.
  • Has open COM interfaces for integration with win32-based 3rd party IDEs.
  • Linux, BSD, SunOs, MacOs and Win32 are supported.
  • &160;



    Xdebug provides:


    Debugger Extension can be downloaded from Zend Downloads

    Zend debugger in Eclipse also works for MySQL statements!

    Installing ZEND debugger in Eclipse

    The Zend Executable Debugger Eclipse plugin adds PHP debugging capabilities to the Eclipse environment.

    Add the following remote location to the eclipse manager, even if you have eclipse PDT

    ZEND debugging mysql statement

    You'll have to configured the PHP binary included with the ZEND debugger to be able to debug SQL queries. Search for a PHP.ini in your eclipse/plugins directory, you'll find 2 files.


    • E:\eclipse\bin\PDT\plugins\org.zend.php.debug.debugger.win32.x86_5.2.12.v20071210\resources\php4\php.ini
    • E:\eclipse\bin\PDT\plugins\org.zend.php.debug.debugger.win32.x86_5.2.12.v20071210\resources\php5\php.ini

    And add these line in one of these files according to your PHP version

    extension_dir = "xampp_path/php/ext"
    include_path =".;xampp_path/php;"

    Installing Zend debugger server in XAMPP

    Please note that the Zend Executable Debugger is not available from the Eclipse PDT update Manager, so download ZEND debugger (Free) from Zend Downloads, you must extract the zip

    In the zip file, you'll see multiple directories

    Use the version that match the one in XAMPP (you have note at chapter A, for me 5.2.3 so copy files from 5_2_x_comp) and copy the dll in


    Open the file php.ini located at xampp_path\apache\bin\php.ini
    and add these keys if they do not already exist:

    ;; Only Zend OR (!) XDebug

    ; this is to see output while debugging
    implicit_flush = On

    Switch off all other debugger as it may conflict with Zen


    Restart apache, check for proper operations by going to http://localhost

    Apache will crash if you have more than one key in php.ini with the name zend_extension_ts, so uncomment all other entries!


    Debugging PHP in Eclipse PDT

    Go to Debug dialog for creating and managing run configurations

    • Choose as Server Debugger: Zend Debugger
    • Choose as PHP Server: XAMPP
    • File should point to the root of your Joomla! installation ex: /PROD2/index.php because in XAMPP htdocs directory I have a subdirectory /PROD2 with Joomla! 1.5 inside
    • Remove the option Break at First Line
    • Keep URL to Auto Generate

    As seen in the screen shot below


    Now click on button configure

    • Give a Name, not important here, lets keep XAMPP
    • Enter the root URL that points to the document root of this server, for me it is http://localhost/PROD2


    Go to tab "Path Mapping"

    • As Path on server enter E:\xampp\htdocs\PROD2
    • Choose Path in Workspace /PROD2



    Confirm all windows, and you can now start the debugger by clinking on debug button zend.debugging.eclipse.joomla_3

    You're done, you can now set breakpoint and debug Joomla! or your code easily






    Installing Joomla in Eclipse

    We will now install Joomla 1.0.15 and Joomla 1.5.1 (newest version at time of writing into eclipse)
    Create two new PHP project in your workspace, one name joomla1.0.x the other joomla1.5.x for example

    Attention: the root workspace must be located at xampp_path/htdocs


    Setting Zend Debugger in Eclipse PDT for Joomla!

    In the PHP perspective of eclipse, go to the menu debug

  • The PDT project is working towards providing a PHP Development Environment framework. This project was formerly known as PHP IDE.

    Make Eclipse PDT work for Joomla development

    Install a PHP debugger

    In order to be able to perform debugging using eclipse PDT, you must download one of the following extra packages:&160; XDEBUG or ZEND debugger. I was not able to get the debugger running with XDEBUG even after reading many tutorials and trial error approach. Both packages are free, and it has work nicely for me with ZEND debugger after 5 minutes...

    Unfortunately, XDEBUG/ZEND can not be packaged with PDT due to license restrictions, so both tools are not just running out of the box without few efforts.

    PDT and Zend Debugger


    PDT + Zend in one package thanks to (118MB), highly recommended

    OR PDT (105MB) and add Zend debugger through software update later

    • Open Eclipse and go to Help-> Software Updates-> Find and Install
    • Select "Search for new features to install" and click "Next"
    • Create a New Remote Site with the following details:
    • Name: PDT
    • URL:
    • Check the PDT box and click "Next" to start the installation

    XAMPP, Zend debugger working together

    open the php.ini located at \xampp\apache\bin\php.ini

    and add the following



    • Only one key zend_extension_ts is allowed per php.ini file, un-comment all other or it wont work,
    • Attention: I did not move ZendDebugger.dll but use the one coming with eclipse Zend plugin, this may cause issues, if you update this plugin and the path change...

    Restart XAMPP apache

    By going to http://localhost/xampp/phpinfo.php check that you have a section Zend Debugger

    Put now a breakpoint in index.php of any Joomla! installation or deeper in any component you want to debug

    And right click on index.php, debug as PHP Web Page (Alt-Shift-D, W)


    While the first page get properly rendered in the internal browser of eclipse PDT, I was getting some strange rendering issues (html code produced look fine), by using an external browser like Chrome, Firefox, the problem has disappear.

    PDT and XDebug

    Installing with PEAR/PECL is as easy as opening a command prompt and typing

    # \xampp\php\pecl install xdebug

    open the php.ini located at \xampp\apache\bin\php.ini

    and un-comment the following



    ;; Only Zend OR (!) XDebug


    1. Modify the correct php.ini file, check the page phpinfo, normally the right php.ini is located at \xampp\apache\bin\php.ini
    2. You need to comment out any other references to &8220;zend_extension_ts&8221; in the php.ini file (the zend optimizer use it already as default)
    3. Restart apache, and check the page http://localhost/xampp/phpinfo.php to make sure XDebug has been successfully installed

    debugging AkoBookPlus:



    Add subversion plugin

    Install subversive by pointing the update manager to subversive update site


    You need also to install SVN connectors by adding a new update site: - [required] Subversive SVN Connectors


    Eclipse will restart, you should be able to browse repositories.

    Happy Joomla! development and PHP debugging!

  • As Git Bisect is not clear a lot of people, here is a nice PDF to look at Enjoy Fighting regressions with git bisect, LinuxCon EU 2013.pdf

    it is about "Linux" combinational explosion... Bug software have the following properties (not desired):

    • has many different "configurations"
    • may fail under one configuration but not another

    N configurations, T tests and C new commits means that a release needs:

    C * N * T tests performed

    where N and T, at least, are growing with the size of the software.

    Git Bisect help find a first bad commit and use a binary search algorithm for efficiency if possible.

  • phpstorm_header

    JetBrains PhpStorm is a commercial IDE for PHP built on JetBrains' IntelliJ IDEA platform.

    PhpStorm provides intelligent editor for PHP code, HTML and JavaScript with on-the-fly code analysis and automated refactoring for PHP and JavaScript code. Code completion supports PHP 5.3 including namespaces and closures.

  • Introduction

    I am presenting here some tips which may help You to correct bugs in programs or applications faster, If you have comments or want to submit new ideas, feel free to do it here
    Being good in the process of solving bugs is more or less a habit:

    • You must discover the right informations (most if the time coming from logs file),
    • Know a little bit the system and how components are interacting each other (software architecture),
    • Use some rules and decide what to do (actions).

    This document is all about theses points...and is targeted for java web applications.


    1. Discovering a bug. Depending on the type of person who report bugs: You, end users, a pool of professional tester, your developer collegues. You will have a different amount of informations and instructions to reproduce it. For a user, assertions like: "The system is not working, the system is slow" is common but it does not contains any real informations, except the fact that something is not working. Most of the time, a persons is responsibble to collect all user&39;s complains, be careful since this person may filter the only useful informations as well. In this phase, you need to collect as many informations as possible.
    2. Use a bug tracking tool, to keep a track of the bug, to have the name of persons and a description how to reproduce it (a web frontend tool like Mantis or Bugzilla is a good start). As a rule: Explain a bug, is the first step for avoiding it! Be descriptive when you assign a ticket in a tracking tool. If you still think You do not need such a tool, the quality of your application, cost controlling and distribution of tasks among developers before shipment will be disastrous,.
    3. Define priorities based on bug severity and assign to a developer (I will suppose it&39;s You :-)). All bug tracking let You define your own subset of priorities.
    4. Define Categories: is it a graphical user interface (GUI), backend, input control problem? All bug tracking let You define your own subset of categories.

      Example of Error Severity Definitions
      taken from Mantis





      Productive operation is not possible.

      - Crash,

      The system cannot be launched.
      1Functional ErrorPrevents the usage of the system

      - A needed function is interrupted,
      - Loss of data, corruption of data
      - Usage of the system is hampered in a way that wrong results are created for critical data.
      - Performance or acceptance.o users

      The system cannot be launched.
      2Median ErrorThe productive usage of the system is possible with some interference (a "workaround" can be established)

      - Deactivate some functions which are not working properly
      - A Hack in done in code which prevent the bug.
      A "workaround" will be implemented for a short time until the problem is properly fixed.
      3Minor ErrorT he system can be used and errors are imperceptible.
      The bug has to be enter in the bug tracking tool.Priority has to be assigned
      4Change RequestNice to have, improvments

      - GUI is not perfect, colors has to be changed, font size, layout
      - Error in Titles, subtitles and blocs of text

      The bug has to be enter in the bug tracking tool.Priority has to be assigned. Usually these bugs are solved if the efforts is small or if developer has some spare time.
    5. Try to reproduce this bug in your development environment, whih is in best case not so much different from production environment. Of course You do not have the same processor or memory or disk but the same software components (database, jvm, classpath, structure of data))
    6. Correct the bug by changing code/avoiding exception case, rewriting algorithm, changing architecture, finding a workaround (hack), adapt functionnalities if it is possible.
    7. In an ideal world:
      1. Write JUNIT testcase(s) to avoid further existence of the same issue. This will greatly improve quality of code!
      2. Document the bugs, correction, and in worst case: a workaround in a central place: a FAQ (Frequently Asked Questions) for developer

    Bug life cycle

    from Mantis



    Loging, logs files

    • Logs file are the oldest way to degug or monitor an application and it&39;s probably the slowest way to debug or locate bugs. Most of the time, you need to reproduce the error in the system, and that can take a lot of time especially if the application has a very complicated workflow. A workflow: dialog and navigation through the application, ex: select a customer, view all account, do a transfer between 2 account This can be the execution of a use-case or a chain of use-cases.
    • It is a common Fact: Without informations, nobody can debug a process and this even with a lot of chance.
    • Worst case: developper use System.err and System.out for everything, they write "bullshit" in log output ("This is value of i= 2"). Developer do not use the same convention: "Exception : oups" or "@EXCEPTION: ioexception". You must force them to use a logging framework and teach them what to write and level of severity.
    • Best case: Your applications is already using a logging framework like Log4j.
      Log4j let You reduce the amount of logs to a special part of your application or keep track of unusual case in a elegant mannner.
      • The amount of logs (Level),
      • The location (file or TCP server, mail or...),
      • The domains in the system (packages, or components, or arbitrary part),
      • The layout is standard because the developer can not influence the apparence, you can add relevant information like thread name, time, date

      All these things can be changed without restarting your application and are controlled by a configuration file (.xml or .properties)!

    • Why logs are sometimes better? because during debugging You may change variables values in realtime to let the bug happen. This is why debugging session are called transient: the know how You bring during these sessions (where you set breakpoints, the iterations You do in code, how you manipulate variables/instances on the fly) is simply lost or not share with your collegue. In this case logging output is better because it may stay even after correcting the bug. This can be useful to avoid further existence of the same bug.
    • Some mistakes:
      • Do not log too much mainly because of performance issues or try to use a preprocessor which remove logging statements before deploying to production...
      • Do not write stupid data during logging, e.g. "this is the value of i" or "iteration i", in this case use the debuger. for the same reasons avoid writing a 100Kb XML, it is useless, write the XML in a file...
      • Do not rely on logging to rescue You from bad code: instead of losing correcting a bad code, why not try refactor it!
    • Log amount can be enormous, especially when you track a bug at the same time with 4000 users working in production on many server (webserver, application server, servlet runner, database cluster).... this is why You "must":
      • Use Unix or install cygwin (if your running under windows) only for having some command like grep, sed, tail, awk, ssh
      • Learn regular expression, to filter the logs file with command like grep, sed, awk
      • Watch logs files in realtime (when users or you are testing your application). Prefer the unix tail command because it is very efficient. You can even combine the tail with a grep command to filter logs output.tail -f Tomcat.out | grep &39;error&39;
      • If You really can not work with a command line, use Jedit which also support regular expression and will probaly have a tail pulgin.

    Silent exceptions

    The worst case in production is what I call "silent exception", these affects some users but not all. They are silent because the users can still use the application but can have some really bad effects afterwards. Example: During a save, your program encounter a problem, but do not rollback the transaction (due to a bad design or implementation) and save an imcomplete state on disk or in the database. In fact, You must really not let them occur, do something before users even remark the problem (It took always 2-3 days before a pool of end-users got crazy about a problem in general, this time is comming from communication channel).

    How to avoid silent exceptions:

    • Define job (can be unix crontab) that parse log files daily or weekly with regular expression, and send a report. With log4j you can for example decide to send an email if a certain error level is thrown (level FATAL fro example)
    • Explain to developer (with a training) differences between logging level, what is fatal, error, warning, what meaningful info they must add in their logging statements. Review their code by checking usage of logging levels, or reading logs when Your application is in DEBUG mode.
    • If you need more error level (better granularity, most of the times it is not a good idea), You may want to define your own level. (and that&39;s easy with log4j)

    Debugger and remote debugging

    The Java Virtual Machine has an interface which allow to remotely debug an application

    Running your application remotely

    The code is running in the developer environment but not in more time there is a difference somewhere, finding it may not be easy...

    • If you are running your application on remote server, are You sure that you deploy the latest code version? this is very easy to test:
      • You can for example run a Unix scripts which compare class CRC or
      • Use beyond compare, a graphical tools to compare directories and contents even through FTP.
      • If You know the class name and package where the exception occurred (look at the stacktrace in log files), use a decompiler like JAD to verify if the latest code is there (follow the rule 1 : "never trust anyone" even You sometimes ;-) )
    • Suspect the classloader:
      • You may have different version of the same class in the classpath = bad deployment
      • The classloader do not respect the servlet guidelines (the servlet runner Resin has some problems for example)
      • Order of jar in classpath, You can have dfferent parser version in different jar files for example.
        In all cases above try:
        • to start the JVM in verbose mode, to see which classes is load a which moment.
        • Use the utility JWhich, inform You where the class was loaded (jar or directory)

    Process throw an Exception of Type X

    • If the process throw an exception and You know the exceptions class created. Use your IDE! all of them have the ability to trigger a breakpoint on that type. The debugger will then stop where the exception is thrown.


    • Do not made a runtime patch (= identifying condition of exception and testing it through IF statements to avoid it), but instead try to find the real reason (design, init phase...) and operate before it occurs, maybe you will need to change your algorithm.
    • Do not correct bug or listen to people which assign too many critical errors, if You can proove that it only affect 0.1% of users in production. Definition of bugs priority is essential as ressources are always limited.

    Automate gathering of informations

    If the system crash, or run in troubles, try to create a journal written on the disk, it can contains

    Example of journal
    - Date: 13.02.2004
    - Application name:
    - Cause:
    - Stacktrace:

    - memory state
    - user name to contact, useful in order to reproduce the bug
    - Meaningful state of the application like
    * http user session
    * main data structure: previous action done,


    • You can look periodically to see if some error appear often enough to be corrected
    • You have some information on the state of the application, if youre design is good enough You can even imagine using/loading this state to put the application in the same status.

    Hotline or developer asking for support

    Capitalize problems and resolutions in a central place!

    • Use FAQ (Frequently Asked Questions) Maybe the error has been already described and a solution found. You may create a lot of FAQs, for developer, manager, hotline. You can not save informations in 1 FAQs for all audience as you may need to adapt responses to the audience.
    • Use the Bugs Tracking tool and search if this bug has exist in the past.
      Example: A new bug has been discover, search in the database, if it has already exist, (bug status closed) then it has to be reopened otherwise you can create a new one.
    • Do not listen to a developer on telephone when He ask for support, or need help and never trust totally what he says (depend on the person of course)! Always ask for the logs files, because most of the time, they tell the truth and based on my experience, nobody really read them!

    No code is perfect, accept it

    • Code is living! and like any living creature it is evolving (both in the good and bad way) Development time will or may improve some parts,
    • Never trust a process ! Before judging that is your process who made the fault, please verify the previous process. (It let you think that you are one of the best programmer 3 minutes more ;-) Sometimes it can be a consecutive error, so only look at the first exception on top of the list.
    • Bug in Apache frameworks or open source projects, of course their code is perfectible, people from Apache try to deliver highly reusable code, but they can not guaranty you that in some particular case it will always work. Remember that some database, OS are existing since 20 years and are constantly improved. So if you find a bug and find an elegant way to handle it, you can send them the corrected code with a short explanation. Do not forget that they do not have your particular application environment, and that they may need to reproduce all conditions before providing a correction to the community (and that&39;s very time consuming).

    Links, references


    "Developers write code. Unfortunately, developers also write defects, most of which are injected during the initial coding phase. The cheapest place to fix these defects is, likewise, during the initial phases of development. If you wait until function or system testing to catch and fix defects, your software development costs will be much higher. In this article , authors Scott Will, Ted Rivera, and Adam Tate discuss some basic "defensive" coding and unit testing practices to make it easier for developers to find defects -- and, more importantly, help to prevent them in the first place."