Derick Rethans - tag: cms

Xdebug 2.1

Tue, 29 Jun 2010 14:17:00 +0000

Xdebug 2.1

Tuesday, June 29th 2010, 15:17 BST

I've just released Xdebug 2.1. This new release contains all the bug fixes and new features that have been developed over the past three years. It provides full PHP 5.3 support, but it no longer supports PHP versions below 5.1.

A description of all the new features follows:

Error Collection

I've added xdebug_start_error_collection(), xdebug_stop_error_collection() and xdebug_get_collected_errors(), which allow you to collect all notices, warnings and error messages that Xdebug generates from PHP's error_reporting functionality so that you can output them at a later point in your script by hand.

Header Setting Interception

All functions that set HTTP headers such as with header() and setcookie() are now intercepted by Xdebug. The intercepted headers are stored internally in an array that can be retrieved by calling the xdebug_get_headers() function. This is very useful in cases where you need to test certain functionality that sets headers somewhere deep in code. This function is also used in eZ Components' test suite to test whether the correct HTTP headers are set in the MvcTools component.

Variable Assignment Tracing

The new setting xdebug.collect_assignments allows you to record changes to variables in scripts to trace files. I've already written more about it in Variable tracing with Xdebug.

"Scream" Support

The scream PECL extension disables the @ (shut-up) operator to actually see all notices, warnings and errors that PHP generates. The scream extension's functionality have been duplicated as Xdebug's xdebug.scream php.ini setting. Why disabling the @-operator is a good thing, I've already outlined in Five reasons why the shut-op operator (@) should be avoided.

Additions for Stack Traces

All HTML containers generated by Xdebug (error messages, xdebug_var_dump() output) now contain a CSS class for easier styling.

The new setting xdebug.file_link_format allows you to turn any file/line link in Xdebug's output to be decorated to a link with a specific format. For example you can set it to txmt://open/?file://%f&line=%l for opening files directly in Textmate, or gvim://%f@%l with some shell script for gvim and Firefox.

Remote Debugging

The new setting xdebug.remote_connect_back, contributed by Lucas Nealan and Brian Shire, allows Xdebug to try to make a debugging connection to the IP address from which the browser request came from. This setting is an additional solution for debugging with multiple users.

The old gdb and php3 remote debugging engines have been removed.

Overloaded var_dump

The newly introduced setting xdebug.overload_var_dump can be used to turn off Xdebug's default behavior of overriding PHP's var_dump() function with the xdebug_var_dump() function that uses pretty HTML for formatting a variable structure. It does not stop xdebug_var_dump() from working however.

Donations

You can probably imagine that writing and support Xdebug is a time-consuming effort. It's a tool that saves a lot of work during developement of applications, as well while debugging. If you think Xdebug is valuable for you, perhaps you would like to consider a donation. All donations are greatly appreciated and support future development and availablity of Xdebug.

If you want to sponsor a (new) feature in Xdebug, feel free to contact me as well.

Download and Support

The new version of Xdebug can be downloaded through the download page. A list with all changes can be found on the updates page. Support information can be found on the support page, and issues and feature requests can be filed in the bug tracker. Before asking for support, please have a look at the FAQ first.

Xdebug 2.1.0 RC1 released

Tue, 06 Apr 2010 13:41:00 +0000

Xdebug 2.1.0 RC1 released

Schiphol, Netherlands

Tuesday, April 6th 2010, 15:41 CEST

As earlier announced in my April Fools' announcement and on Xdebug's twitter feed, I'm now releasing Xdebug 2.1.0RC1. This is the first Release Candidate and it addresses a number of issues found in the latest beta. As I usually do in release announcements, I will also be introducing a new feature in Xdebug 2.1 in this one.

In an article that I wrote a few months ago, I illustrated a few different reasons on why the shut-op operator (@) should be avoided. Although there are a few cases where it simple can not be avoided if you want to write notice-free code, the main reason why this operator should be avoided, is because it makes debugging quite a bit more difficult if errors are hidden.

Xdebug is a debugging aid to make debugging easier. So from version 2.1.0 there is a new configuration setting — xdebug.scream — that simply disables the effects of the @ operator. That means that all errors will be shown, of course, still listening to the error_reporting and display_errors settings. This functionality is not a novel thing, and the idea was lifted from the PECL scream package. However, I think this functionality fits in very well with all the other things that Xdebug has to offer.

Just to mention it once more, I have no intention of making Xdebug closed source. I spend a considerable amount of time in adding new features and addressing issues, so I would appreciate it that if consider a donation in case Xdebug has saved you time and effort in debugging your application. If you have comments or suggestions to improve Xdebug, please write to the mailinglist.

First release of the D-Bus extension

Tue, 06 Apr 2010 09:33:00 +0000

First release of the D-Bus extension

London, UK

Tuesday, April 6th 2010, 10:33 BST

A few days ago I made the first beta release of the D-Bus extension that I have been working on for a while. D-Bus is a message bus system, a simple way for applications to talk to one another. I started working on this because my cellphone, an OpenMoko FreeRunner. This cellphone (or rather, a mobile Linux computing device) implements freesmartphone.org APIs to talk to all the hardware that is available on the device. This includes GSM and SIM card interfaces, but also GPS, Audio and PIM services.

However, many other applications on the Linux desktop speak D-Bus. This includes system services such as the notification daemon, the screen saver and hardware plug-in detection as well as desktop applications such as Pidgin and Empathy.

I've given a presentation on the extension at the PHP London conference earlier this year, and will also be speaking on this subject as part of the "PHP Inside" and "PHP on the D-Bus" talks at Tek-X (Chicago, May 18-21), International PHP Conference Spring (Berlin, May 30-June 2) and the Dutch PHP Conference (June 10-12).

Xdebug no longer Open Source

Thu, 01 Apr 2010 09:19:00 +0000

Xdebug no longer Open Source

London, UK

Thursday, April 1st 2010, 10:19 BST

This was obviously an April Fools' joke, Xdebug will continue to stay Open Source and free of charge.

Later today I will be releasing the first Release Candidate of Xdebug 2.1. With regret I have to announce that from this release, I will no longer provide Xdebug as an open source debugger extension. I've noticed that there are other projects making money of Xdebug's success while I only receive donations from a group of awesome supporters.

Xdebug will continue to be available for benefactors on a limited number of platforms that I have access to (Linux 32/64bit and Windows). Please refer to the FAQ for further information.

Storing Date/Times in Databases

Mon, 29 Mar 2010 15:47:00 +0000

Storing Date/Times in Databases

London, UK

Monday, March 29th 2010, 16:47 BST

After my talk during ConFoo on Advanced Date/Time Handling I received a question about whether the UTC-offset, together with the date/time in years, months, days, hours, minutes and seconds, was enough for storing a date/time in a database and still being able to do calculations with this. The answer to this question was no, but it lead to an even more interesting discussion about what would be enough to store an accurate date/time in a database.

Firstly let me explain why storing a UTC offset is not adequate at all for doing any sort of calculations. Right now (March 25th, 2010), Montreal is on the same time as Santiago (in Chile) with both a UTC offset of -4 hours. This means that for the same date/time (2010-03-25 19:03) the same timestamp is generated (1269558180). However if we want to add eight months (2010-11-25 19:03) to the current time for each of those locations then the timestamps should be different — 1290729780 for Montreal and 1290722580 for Santiago. It turns out that neither of them is exactly a full 24 hour difference from 2010-03-25 19:03 as is shown the following script:

format( 'U' );
$santiagoNow = date_create( "{$s} America/Santiago" )->format( 'U' );
$s = '2010-11-25 19:03';
$montrealThen = date_create( "{$s} America/Montreal" )->format( 'U' );
$santiagoThen = date_create( "{$s} America/Santiago" )->format( 'U' );

$hour = 60 * 60;
$day = 24 * $hour;

echo "Montreal:\n",
    $montrealNow, " - ",
    $montrealThen, "\n",
    ( ( $montrealThen - $montrealNow ) % $day ) / $hour, "\n\n";

echo "Santiago:\n",
    $santiagoNow, " - ",
    $santiagoThen, "\n",
    ( ( $santiagoThen - $santiagoNow ) % $day ) / $hour, "\n\n";

?>

which gives the output:

Montreal:
1269558180 - 1290729780
1

Santiago:
1269558180 - 1290722580
23

From this we see that Montreal has an extra hour and Santiago has an hour less. This is because Montreal changed from Daylight Savings Time to normal time and Santiago, being on the southern hemisphere, moved from normal time to Daylight Savings time.

Now if we had only the timestamp (1269558180) and the UTC-offset, the only thing we could do would be to advance a specific number of days. In this case, there are 245 days, which makes (245 * 24 * 60 * 60 = ) 21168000 seconds. If we add this to the original timestamp, we end up at 1290726180 which corresponds to 2010-11-25 18:03 Montreal time, or 2010-11-25 20:03 Santiago time. Neither of them being the correct 2010-11-25 19:03. Because from the UTC offset of 4 hours we don't know whether we're in Montreal or Santiago, we can conclude that with just this UTC offset and the original timestamp we can't calculate the timestamp of something that's 8 months in the future. Storing the UTC-offset can not change this fact either.

In order to to proper calculations, you need to keep information about the timezone itself. In PHP timezones are identified with identifiers such as America/Montreal. If we store those alongside the timestamps, we can do the proper calculations. The following example demonstrates that:

setTimeZone( new DateTimeZone( $tzid ) );
$d->modify( '+8 months' );

echo $d->format( 'Y-m-d H:i' ), "\n";
?>

which gives the output: 2010-11-25 19:03.

This seems to work, but unfortunately, even the approach of storing the timestamp and timezone identifier is not going to work correctly under certain circumstances. In order to find out why, we have to go back to January this year.

Imagine that in January this year—January 15th to be precise—we run the following script to determine the timestamp of a date/time two months in the future:

format( 'U' );

$d = new DateTime( "@$ts" );
$d->setTimeZone( new DateTimeZone( $tz ) );
$d->modify( '+2 months' );

echo $d->format( 'U Y-m-d H:i' ), "\n";
?>

This returns the timestamp 1268664060 for the date/time 2010-03-15 10:41:00.

Now skip forwards to the current date and time. If we used this calculated timestamp and the timezone identifier America/Santiago today to generate a date/time string, we would however get a different output. The following example shows this:

setTimeZone( new DateTimeZone( $tz ) );

echo $d->format( 'Y-m-d H:i:s' ), "\n";
?>

which gives the output: 2010-03-15 11:41:00 (and not 2010-03-15 10:41:00).

The difference in output is not a bug, but is caused because some countries change Daylight Savings Time rules quite frequently. In this case Chile decided (on March 4th) that instead of going forwards to DST at midnight March 14th, they will delay that to April 4th. When we ran the code on January 15th, the rules still thought that March 15th would already be on normal time again, outside of DST. But running the code now, with the updated rule set, we find that DST is still in effect until April 4th. The following example shows the transitions from/to DST for Santiago in 2010:

getTransitions(
    strtotime( '2010-01-01 00:00 UTC' ),
    strtotime( '2010-12-31 00:00 UTC' )
);

foreach ( $transitions as $t )
{
    echo $t['time'], ' ', $t['offset'] / 3600, ' ', $t['abbr'], "\n";
}
?>

If we run this script with PHP 5.3.1 or 5.3.2—which still have the old incorrect rule set—the output is:

2010-01-01T00:00:00+0000 -3 CLST
2010-03-14T03:00:00+0000 -4 CLT
2010-10-10T04:00:00+0000 -3 CLST

In the SVN repository, the rule set has been updated, so snapshots of PHP 5.3-dev have the correct rules and the script will show:

2010-01-01T00:00:00+0000 -3 CLST
2010-04-04T03:00:00+0000 -4 CLT
2010-10-10T04:00:00+0000 -3 CLST

This leads to the conclusion that storing timestamps and timezone identifiers is not good enough either, unless you want an exact point in time, as opposed to the more expected date/time in a location. So how should you store the latter then? Basically, in the same way that DateTime objects are serialized in PHP 5.3. Let us imagine again, that the following code is run on January 15th again:

modify( '+2 months' );
$s = $d->format( 'Y-m-d H:i:s' );
$ts = $d->format( 'U' );
echo "$s (ts=$ts)\n";
?>

which gives the output 2010-03-15 10:41:00 (ts=1268664060). The next example is run with a recent rule set (such as in PHP SVN) today:

format( 'Y-m-d H:i:s' );
$ts = $d->format( 'U' );
echo "$s (ts=$ts)\n";
?>

which gives the output 2010-03-15 10:41:00 (ts=1268660460). As you can see, now the date/time itself is correct, although there is a different timestamp. PHP's DateTime serialisation does something similar:

setTimeZone( new DateTimeZone( 'America/Santiago' ) );
var_dump( $d );
?>

which gives the output:

object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-03-29 11:32:08"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(16) "America/Santiago"
}

For things to work correctly, you need to have an up-to-date rule set. PHP versions are not released as often as the timezonedb (sometimes more than 20 times a year) and to address this issue you can install the pecl extension timezonedb with pecl install timezonedb.

To store information in a database, I would use a char column-type to store the whole America/Santiago timezone identifier and another char column-type to store the date/time (in the yyyy-mm-dd hh:ii:ss format). Alternatively, you can pick a 'datetime' column-type, as long as that type ignores timezones altogether. For MySQL that is the DATETIME column-type, and for PostgreSQL the TIMESTAMP or TIMESTAMP WITHOUT TIME ZONE column-types.

Databases rarely handle timezones, daylight savings time and rule changes correctly, so avoid the database specific functionality all together. Using either a char or a timezone-less 'datetime' column-type would still allow you to sort and by using a 'datetime' column-type you can even do calculations.

Happy summer time!

Available for PHP Extension Writing

Mon, 15 Mar 2010 12:28:00 +0000

Available for PHP Extension Writing

London, UK

Monday, March 15th 2010, 12:28 GMT

Slightly more than a month ago I left my job as team-lead of eZ Components at eZ Systems behind, to focus on something new. During the past month I've been contemplating about what to do next and realized that I do not want to take on a new full-time position right away. Instead I will be available to work on (custom) PHP extensions and internals related issues. Extensions are a great way around PHP's limitations and performance issues.

As first project I am working on a "QuickHash" extension for StumbleUpon. This extension circumvents PHP's hefty memory (and performance) overhead by providing more specific data structures. The extension currently implements integer sets and integer to integer hashes. I am now adding integer to string hashes and string to integer hashes. The QuickHash extension will be released under the PHP Licence and I will dedicate another post to it later.

If, like StumbleUpon, you are also interested in having work done on PHP or a specific extensions feel free to contact me. I'd be happy to discuss things with you.

New Xdebug browser extensions

Wed, 17 Feb 2010 12:33:00 +0000

New Xdebug browser extensions

London, UK

Wednesday, February 17th 2010, 12:33 GMT

Years ago I wrote about a Firefox extension that allows you to start an Xdebug debugging session by clicking on an icon in Firefox' status bar. For some unexplained reason, this extension is no longer available through Firefox' addon-site. Although I have a copy at http://xdebug.org/files/xdebug_helper-0.3.1-fx.xpi for archival purposes, there are now a few other browser extensions that do the same thing.

easy Xdebug

easy Xdebug is an extension that serves as a replacement for the now unavailable Xdebug helper extension. It's written by Brecht Vanhaesebrouck of eLime. The extension was originally tested with Netbeans but it also seems to work fine with Komodo.

Xdebug enabler

Xdebug enabler is an extension for Google's Chrome browser. It "allows you to enable and disable triggering Xdebug from with in Chrome. Useful if you are a web developer using an IDE that supports Xdebug like Eclipse with PDT." It's written by 'remailednet' and available through the Google Chrome Extensions website.

JavaScript 'enabler'

I also ran across a blog post by 'Caleb G' from HigherVisibility. Instead of making an extension for a specific browser, he outlines two JavaScript bookmarklets that allow you to start and stop an Xdebug debugging session.

Update: The "Xdebug enabler" Chrome Extension seems to have some issues. There is now also an alternative Chrome Extension called Xdebug helper that integrates quite a bit better. You can find it at its Google Chrome Extension page.

Xdebug moved to a new server

Fri, 27 Nov 2009 14:42:00 +0000

Xdebug moved to a new server

London, UK

Friday, November 27th 2009, 14:42 GMT

Xdebug 's CVS server was previously hosted at eZ Systems' office, but as I am leaving soon I needed to move this to a different server. At the same time, I decided to also convert from CVS to SVN. So from now on, there is no more cvs.xdebug.org, but just a svn.xdebug.org. This SVN server doesn't only host Xdebug, but also some of my other projects, such as VLD (opcode dumper to aid PHP engine development), the DBGp specs (debugger protocol as used by Xdebug and ActiveState's debuggers) and my OpenMoko perversions and projects.

Xdebug can now be checked out from SVN with:

svn co svn://svn.xdebug.org/svn/xdebug/xdebug/trunk xdebug

All other Xdebug services (mailinglists, web, e-mail and the bug system) moved to the same server as well. Just be aware that DNS servers might still need updating when you try to access the new services.

Xdebug and tracing memory usage

Fri, 13 Nov 2009 11:59:00 +0000

Xdebug and tracing memory usage

London, UK

Friday, November 13th 2009, 11:59 GMT

Recently people started to ask me how to use Xdebug to figure out which parts of applications use a lot of memory. Traditionally this was part of Xdebug's profiling functionality. Unfortunately the cachegrind format didn't fit this so well, and because it returned incorrect data I removed this functionality from the profiler. However, there is other functionality in Xdebug that does provide the correct data: the function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it. With the last two numbers it's rather trivial to write a script to figure out which functions/methods increase the memory usage a lot. Of course, nobody had written a script yet to do anything with this information

As part of my preparations for my Xdebug talk at IPC next week, I now have written such a script. The script parses the tab-separated function trace files and aggregates all the information by function name. You can sort the output on a few different keys: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure how many elements it will show. As an example here is some output from a trace of one of the presentation system's PHP scripts:

$ php tracefile-analyser.php trace.2043925204.xt memory-own 20

parsing...
Done.
Showing the 20 most costly calls sorted by 'memory-own'.
                                               Inclusive        Own
function                               #calls  time     memory  time     memory
-------------------------------------------------------------------------------
require_once                                9  0.0541  4595160  0.0277  2548104
{main}                                      1  0.0600  2906032  0.0034   249744
fread                                       4  0.0001    33296  0.0001    33296
session_start                               1  0.0002    31824  0.0002    31824
XML_Presentation->startHandler             38  0.0073    36360  0.0035    18424
_pres_slide->_pres_slide                   27  0.0009    10152  0.0009    10152
_presentation->_presentation                1  0.0001     7912  0.0001     7912
strtolower                                 67  0.0017     6456  0.0017     6456
compact                                     1  0.0000     4832  0.0000     4832
each                                        5  0.0001     4320  0.0001     4320
XML_Presentation->endHandler               38  0.0014     3800  0.0014     3960
_slide->_slide                              1  0.0001     3896  0.0001     3896
XML_Slide->startHandler                     4  0.0009    10800  0.0004     3736
_image->_image                              1  0.0000     3040  0.0000     3040
fopen                                       2  0.0001     2816  0.0001     2816
getimagesize                                1  0.0001     2296  0.0001     2296
display->display                            1  0.0001     2120  0.0001     2120
explode                                     2  0.0001     2120  0.0001     2120
xml_parser_create                           2  0.0001     1680  0.0001     1680
XML_Parser->_initHandlers                   2  0.0011     1600  0.0005     1360

The script is available from SVN by running:

svn co svn://svn.xdebug.org:/svn/xdebug/xdebug/trunk/contrib xdebug/contrib

The script to run is then "tracefile-analyser.php" from inside the "xdebug/contrib" directory.

Update 2009-12-28: Changed the CVS instructions to the new SVN instructions.

Good bye eZ Systems

Tue, 27 Oct 2009 10:36:00 +0000

Good bye eZ Systems

London, UK

Tuesday, October 27th 2009, 10:36 GMT

During the past 6 years I've been working as a developer for eZ Systems — first as a developer on eZ Publish and later as project lead for eZ Components. Working on a project like eZ Components as lead was challenging and interesting and taught me many things. eZ Systems as a company is changing a lot, and now the time has come for me to move on and find something new and exciting to do. I've recently moved to London to explore life from a different point of view, and that will now also include a search for a new challenge professionally. I will still be with eZ Systems for awhile longer to finish the next eZ Components release. If you think you can provide me with a new challenge, feel free to contact me.

Debugging with multiple users

Thu, 11 Jun 2009 08:47:00 +0000

Debugging with multiple users

Amsterdam, the Netherlands

Thursday, June 11th 2009, 10:47 CEST

As author of Xdebug, people ask me often the question how to handle the case in teams when there is one development server and multiple developers working on the same project on that server. Xdebug only allows you to specify one IP address to connect to (through xdebug.remote_host ) while doing remote debugging. It does not automatically connect back to the IP address that runs the browser the request the PHP scripts because of security reasons. You don't want everybody on the Internet to be able to run a debugging session against your code for example. There is no problem if all developers are working on a different project, because the xdebug.remote_host setting can be made for each directory (through Apache's .htaccess functionality). However, for the case where multiple developers work on the same code, the .htaccess trick won't work as the directory in which the code lives is the same.

Now, in order to solve the above mentioned issue, you will need to run a DBGp proxy. DBGp is the protocol, designed by ActiveState and myself to facilitate communication between an IDE (such as Komodo, or any of the other listed clients ) and PHP+Xdebug. A DBGp proxy is a bit of software that acts as a redirector for DBGp streams. In order to make things work for multiple developers and one source base, you set Xdebug's xdebug.remote_host setting to the machine on which the DBGp proxy runs. This is most likely going to be on the same machine that acts as development server, so that the xdebug.remote_host setting should be set to "127.0.0.1" (i.e. localhost). The proxy server the listens for IDE connections. An IDE needs to register itself with the DBGp proxy by using the proxyinit command. This command requires an "idekey" that is a unique identifier for each client (IDE). Every developer should have its own unique idekey (I usually just pick my name), and this idekey should be configurable in the IDE. For Komodo, it's at Edit->Preferences->Debugger->Connection->"I am running a debugger proxy and Komodo should use it"->"Proxy Key". In Komodo you also need to select "a system-provided free port" in the same configuration panel. When initiating the debugging session from the browser with either XDEBUG_SESSION_START=session_name as GET/POST/COOKIE parameter, or export XDEBUG_CONFIG="idekey=session_name" from the comment line, make sure to change "session_name" to the idekey as configured in your IDE. (See the documentation on how to set this up). The Xdebug Firefox extension also has a setting for this. You have to configure Xdebug's xdebug.remote_host setting to the IP address of the machine that the proxy runs at. Xdebug itself does not see a difference between either the proxy and a normal IDE. But the proxy itself now knows because of the configured idekey on how to forward the requests and responses to the correct client.

You can find the DBGp proxy code as part of the python remote debugging package that ActiveState provides. By default it listens for IDE registrations at port 9001, and for Xdebug connections at port 9000. To run the proxy, do:

tar -xvzf Komodo-PythonRemoteDebugging-5.1.3-28369-linux-x86_64.tar.gz
cd Komodo-PythonRemoteDebugging-5.1.3-28369-linux-x86_64
cd bin
./pydbgpproxy

This outputs:

INFO: dbgp.proxy: starting proxy listeners.  appid: 30430
INFO: dbgp.proxy:     dbgp listener on 127.0.0.1:9000
INFO: dbgp.proxy:     IDE listener on  127.0.0.1:9001

Running a DBGp proxy also allows you to avoid NAT issues where (as seen from PHP+Xdebug on the server) all connections seem to come from the same IP (because your internal network is NATted). In this case, you can simple run the dbgp proxy on your NAT machine, configure xdebug.remote_host setting to the IP address of your NAT machine, and configure the IDEs to connect to the proxy running at :9001.

As a last note; there is a patch to allow the connect-back-to-requesting-IP-address functionality that is not available directly in Xdebug. This patch, written by Brian Shire and Lucas Nealan of Facebook made its way into Xdebug 2.1. However, great care should be taken by using this functionality. It does not make the NAT situation as outlined above work however.

PHP's two-pass compiler

Sat, 24 Jan 2009 18:55:00 +0000

PHP's two-pass compiler

Istanbul, Turkey

Saturday, January 24th 2009, 20:55 EET

On my way to Istanbul I was looking at Xdebug bug #422 . For some reason Xdebug was crashing while doing code-coverage analysis, in the part that analyses which code was dead (ie. opcodes that could never be reached). The crash occurred with a JMPZ (jump-if-zero) instruction, that suddenly saw a jump-to position of 572222864. That position resembles more a jump-address.

Xdebug uses the same branch analysis implementation as VLD so I used the latter tool to find out why it would crash. Unfortunately, it was working just all nice and fine with VLD. After digging around some more, I saw from the back trace that the crash in Xdebug only occurred when a user-defined error-handler was called while parsing a file. The latter gave me the insight of looking at which phase the compiler was in. I remembered that PHP has a two phase compiler. The first pass is quick and dirty, and only records the opcode line number to jump to. Xdebug however was expecting an memory address as jump target. Because a memory address is a much larger number than an opcode number—the latter usually not being much higher than a thousand—Xdebug was setting the "visited" flag in a part of memory that wasn't allocated. And writing to unallocated memory makes a process die with a segmentation fault.

The compiler in PHP is two-pass. During the first pass, it will find out to which opcode it needs to jump in the jump instructions. However, the PHP engine (and Xdebug) expects a memory address to jump to while executing your script. In the second pass, the compiler will then go over the generated opcodes and calculate the memory address to jump to from the jumps to opcode numbers. It will also do a few other things, such as collapsing sequential EXT_STMT opcodes, calling Zend extension's functions to finalize the opcode arrays—Xdebug uses this for caching whether an opcode array has been scanned already—and re-allocating the opcode array itself to save space.

Now, the thing is, that usually VLD and Xdebug kick in after the whole opcode array has been created, which includes running the second pass of the compiler. However, Xdebug also tries to analyze opcode arrays while executing them. In the case of a user defined error handler, that happens before the second pass has been run. Preventing the crash was therefore as easy as making sure that the compiler's second pass had been run while scanning the opcode arrays for executable code.

Conferences in Winter/Spring 2009

Tue, 13 Jan 2009 09:47:00 +0000

Conferences in Winter/Spring 2009

Skien, Norway

Tuesday, January 13th 2009, 10:47 CET

In the next five months I've lined up quite a few conferences. First of all, there is Web Programcıları Platformu in Istanbul, where I will be giving the closing keynote to inspire Turkish talent on January 24th.

The week after that I'll be traveling to Barcelona for the eZ International Winter Conference to give a tutorial to the new MvcTools component.

In March I will speak at PHP Quebec Conference on searching with PHP , simple application design and eZ Components .

In April I will travel to Veliko Tŭrnovo in Bulgaria to speak at the WebTech conference on PHP-on-DBUS and Test Driven Development.

The line-up ends with a trip to Chicago to give a talk on searching with PHP , simple application design .

Leap Seconds and What To Do With Them

Thu, 01 Jan 2009 22:03:00 +0000

Leap Seconds and What To Do With Them

Skien, Norway

Thursday, January 1st 2009, 23:03 CET

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

There are many different time keeping scales. They are either defined as an arbitrary value, or obtained from astronomical observations. First of all, there are the variants of Universal Time. UT1 is the principal form of Universal Time. UT1 is the same all over the world, and is related to the Earths rotation. The rotation speed of the Earth is not precise, and is slowed down by the tidal friction of the Moon among things. Obviously, this is a bad base to build a stable and precise timekeeping scale on.

An (SI) second is nowadays defined as "the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom". This can be measured very accurately by atomic clocks and is the base for International Atomic Time (TAI, from Temps Atomique International). This scale however, does not take into account the gradual but increasing slowing down of the Earth's rotation and will therefore not reflect the approximation to "mean solar time" over longer periods of time. This makes it useless as a civil timekeeping scale.

For the latter purpose, Coordinated Universal Time (UTC, from Universal Time, Coordinated) has been established. UTC uses SI seconds but is adjusted for the slowing down of Earths rotation with leap seconds. Because it's not possible to predict the rotation of the Earth upfront, leap seconds are only added when the difference between UTC and UT1 approaches 0.6 SI seconds in order to keep UTC and UT1 not differ from each other for more than 0.9 seconds. UTC was defined (in the latest adjustment of its definition) as being 10 seconds different from TAI making 1972-01-01T00:00:00 UTC and 1972-01-01T00:00:10 TAI the same instant. Since 1972, 24 leap seconds have been introduced, making TAI differ from UTC with 34 seconds currently. As the Earth's rotation is slowing down at an ever increasing rate, the use of leap seconds will get more and more annoying. After the 25th century, it is likely that more than 4 leap seconds would be required every year. This is of course highly unpractical and a solution needs to be found for this.

There are two other timescales based on TAI. Terrestial Time (TT) as the modern astronomical standard for the passage of time. TT is defined as TAI + 32.184 seconds. GPS Time, as used by GPS satellites and receivers, was set to match UTC in 1980, but now deviates with 15 seconds due to the addition of leap seconds in UTC. GPS Time is defined as TAI - 19 seconds.

Greenwich Mean Time (GMT) is often used as synonym for UTC, although that is strictly not correct. GMT is an astronomical concept and therefore linked to UT1. Greenwich Mean Time is also used as timezone name for a timezone with zero seconds offset from UTC. It is for example used in winter in the UK and Ireland. During the summer, when the UK and Ireland switch to daylight savings time, GMT is not used at all. British Summer Time (BST) and Ireland Summer Time (IST) are then used instead.

A thing to realize is that leap seconds are added only at the end of June 30th and December 31st. The seconds are added at 23:59:59 UTC . This means that there is no need to add an extra second while counting down to the new year unless you're in a timezone that is UTC +0 seconds (such as GMT, or WET). Of course, in other locations the leap second is inserted as well at the same time. In Norway, the leap second was added at Jan 1st, 2009, at 00:59:59 for example.

Unix time (also called POSIX time) is defined as the number of seconds since Jan 1st 1970, 00:00 UTC, but without leap seconds. Although it is called Unix time , this timekeeping standard is used widely in many other operating systems and computing devices. Unix time simply counts the number of seconds since the epoch. A date/time expressed in those seconds is often called a Unix time stamp. Not supporting leap seconds means that Unix time does not have any way to represent the leap second in the form of 23:59:60. Instead it just uses the same second twice. In practical terms, that means that Unix time progressed like this during the year transition: 1230767999, 1230768000, 1230768000 and 1230768001. The first 1230768000 represents 2008-12-31 23:59:60 UTC, and the second 1230768000 represents 2009-01-01 00:00:00 UTC. For applications there is no way to differentiate between the two distinct times, although many applications will accept both as input, like this PHP example shows:

In order to synchronize the system time the Network Time Protocol (NTP) is widely used. NTP can use different sources of time information in an hierarchical fashion. The protocol knows how to deal with leap seconds to provide the correct Unix time stamp.

To recap the above information: UT1 is based on the actual rotational speed of the Earth and is therefore never accurate. TAI is a time scale based on the actual count of SI seconds. UTC also uses SI seconds, but requires a leap second in order not to deviate from the unstable UT1 which is in sync with the average time of when the Sun is due South (mean solar time). Unix time counts SI seconds, and resembles UTC except that instead of leap seconds, the Unix time stamp is simply used twice. GMT is both a different name for UT1 and a name for a timezone with an UTC offset of 0 seconds. PHP uses Unix time, and does not care about leap seconds.

Happy New Year!

Xdebug 2.0.4

Tue, 30 Dec 2008 15:46:00 +0000

Xdebug 2.0.4

Dieren, the Netherlands

Tuesday, December 30th 2008, 16:46 CET

I just released Xdebug 2.0.4 which addresses bugs from the Xdebug 2.0 branch, including bug fixes related to crashes on Vista. You can get Xdebug through PECL (pecl install xdebug) or from the Xdebug site. Windows binaries will be made available later.