Derick Rethans - tag: work

Xdebug no longer Open Source

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

Xdebug no longer Open Source

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.

New website layout

Sat, 26 Dec 2009 15:13:00 +0000

New website layout

London, UK

Saturday, December 26th 2009, 15:13 UTC

Just like Xdebug's server was moved 1 to a new VPS at XtraHosting so did my personal website (the one you're looking at). Hosting it on my own gives me full control over what software runs it, and which PHP version and extensions I run. I switched most of the code from a PHP 4.1 atrocity to PHP 5.3 goodness.

At the same time, I also moved all the contents from some self-invented XML format to reStructuredText. reStructuredText is a format that can be parsed and transformed into other formats by eZ Components' Document component. Right now I am transforming to HTML only, but in the future I will also transform certain articles to PDFs. Comments can also make use of some of the reStructuredText formatting options, but there are still some things that need sorting out there.

Besides changing the layout and converting the content to a more manageable format, I also introduced a stream of dopplr, flickr and twitter updates on the right side. This is implemented by parsing the relative RSS feeds from the different sources. If location information is present, this is also shown in this feed. Previously I would only export an RSS feed for all of the content, but with this site update, there is now a feed for every tag that I've used. All RSS functionality is provided by the Feed component of eZ Components (although a patch is currently needed for the location information).

I'm not a 100% happy with the new layout, so most likely I will be doing some changes in the near future.

1
http://derickrethans.nl/xdebug-moved-to-a-new-server.html

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.

Unix Epoch and PHP's calendar system

Thu, 12 Nov 2009 12:32:00 +0000

Unix Epoch and PHP's calendar system

London, UK

Thursday, November 12th 2009, 12:32 GMT

I just saw a commit flying past as a response to PHP bug #50155. While right now it is proper to define the Unix Epoch at "1970-01-01 00:00:00 UTC", UTC wasn't actually defined until 1972. So it would be more correct to define the Unix Epoch as "the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (from Wikipedia). What the bit "not counting leap seconds" means, I've already explained before in Leap Seconds and What To Do With Them.

Similarly, PHP's internal calendar is the ISO 8601 calendar. This is a modification of the proleptic Gregorian calendar. The Gregorian calendar implements the current set of leap years every 4 years, but not every 100 years, but again every 400 years (to get to an average year length of 365.2425 days). Obviously this calendar is only in use since 1582 (some countries adopted it as late as the 1900s), so using days like 1066-10-14 in the Gregorian calendar makes little sense because that calendar didn't exist back then. Now, PHP's ISO 8601-based calendar even modifies the Gregorian calendar by including the year 0. The Gregorian calendar goes straight from -1 to 1 which is a pain to do proper date calculations with. Therefore the ISO 8601 calendar uses Astronomical year numbering.

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.

Autumn Plans

Mon, 14 Sep 2009 12:26:00 +0000

Autumn Plans

London, UK

Monday, September 14th 2009, 13:26 BST

I've been missing-in-action on my own blog for some time. Moving to London does that to you. Anyway, I've not been idle in the meanwhile at all, and been working on some cool side-projects. First of all I've been adding some features to Xdebug . Xdebug is now slow reaching beta-status for the 2.1 release. New feature will include proper PHP 5.3 support, variable tracing, "scream" support and other minor features.

Besides Xdebug I've also been hacking on PHP-GTK applications for my phone . The major new thing that I have now is a PHP-GTK twitter client that works like I want it... and I even use it on my desktop instead of all the other stuff that's out there. I will soon be publishing this client in my CVS repository.

Now that the conference season is starting again I'm working on improving several talks, as well as rewriting some parts for them. The first conference that I will be speaking at, are part of "Marco's Crazy PHP Conference Tour" aka CodeWorks . I'll be giving three different talks here, one on "Debugging with Xdebug ", one on PHP's DateTime support and one on "Improving your development process" where I'll be talking about Test-Driven Development and other tricks associated by running a project. As CodeWorks is a bit like a rock-star tour, I'll be keeping a video blog of it somewhere on the intertubes.

Good bye Norway, Hello London

Sun, 21 Jun 2009 00:32:00 +0000

Good bye Norway, Hello London

Skien, Norway

Sunday, June 21st 2009, 02:32 CEST

Today, at the longest day of the year at the summer solstice , I am making a bit change to my life. If you're following me on twitter you probably already know what I'm up to. For everybody else, I am going to say good bye to Skien in Norway, and move to London (the one in England, and not the one in Ontario). Norway has been my home for the past five years, and I've had a great time exploring the nature as well as working at our office in Skien . Skien is a nice place, but ... not the most interesting of cities in the world. From today I will be living in London to see what life will bring me there. I am both sad to leave Norway, but I am also excited to live in a cool new place like London. I'll have awesome house mates (Hi, Mr. Þorbjörnsson, Ms. Cherry and Mr. Ray!!), and something new to put my energy in. I will continue to work as project leader for eZ Components for eZ Systems and continue to make great software with Alexandru, Tobias , Kore and Sebastian . If you are about in London, let me know! We could go for a pint or something. See you there!

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|architect's Guide to Date and Time Programming

Wed, 03 Jun 2009 19:06:00 +0000

php|architect's Guide to Date and Time Programming

Skien, Norway

Wednesday, June 3rd 2009, 21:06 CEST

In the past year I've been working on a book, describing PHP's Date and Time functionality in great detail. It's now finally out under the name " php|architect's Guide to Date and Time Programming ". Look at the pretty cover! It's actually a picture I took some months ago from the church in Skien , where I am still living (more about that in a later post).

The book is devoted on helping you understanding dates and times, as well as how PHP deals with it. It explains how PHP parsers and reads dates and times in strings including possible pitfalls; timezones, their history, the annoyances and how to deal with them properly; formatting and displaying dates and times; and last but not least, how to handle intervals and iterating over time. There is more information on the website where you can also buy this awesome book. And in case you're wondering "what? dates and times are really simple!", then this book is definitely for you.

Rumour is that all attendees of the Dutch PHP Conference will receive a copy with their tickets, if you're asking nicely I might even sign your copy! I'll be there to give a talk on "PHP on the D-BUS" and will show you how to talk to skype, GSM chips and other desktoppy things!

pfcongrez, P2P Конференция, php|tek, PHP Vikinger, DPC and eZ Conference and Awards

Thu, 09 Apr 2009 23:45:00 +0000

pfcongrez, P2P Конференция, php|tek, PHP Vikinger, DPC and eZ Conference and Awards

London, UK

Friday, April 10th 2009, 01:45 CEST

The above mentioned conferences all have one thing in common: I'll be speaking. At the first conference, pfcongrez I will be talking on implementing Test Driven Development as a model for software development. A modified version of this talk I will also give at the next conference, P2P Конференция (P2P Conference) in Bulgaria. At this same conference I will be talking on using PHP as development language for GSM based applications on mobile computing platforms running Linux, where I will use the pecl/dbus extension to talk to the interface framework available on the OpenMoko platform. This same talk I will also give at DPC in Amsterdam. In between however I will go to Chicago to speak at php|tek on search technologies in my "Haystacks and Needles" talk and on simple architecture in my KISS talk. Before DPC I will also go to Leuven for PHP Vikinger , an unconference that I'll be organizing for the 3rd time. This year it is no longer in Norway, but instead we moved to Leuven in Belgium. It is also de-coupled from the eZ Conference and Awards which will be in Paris.

PHP Vikinger 2009

Mon, 06 Apr 2009 11:36:00 +0000

PHP Vikinger 2009

London, UK

Monday, April 6th 2009, 12:36 BST

I'll be organizing PHP Vikinger again this year. It will not be in Norway, but instead we'll be moving to Leuven in Belgium. It will be held on May 30th, very close to Leuven's central station at Café Sport (known from the PHP Belgium meetings). For the full invitation, see the website .

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.