This was found on a 5.3.2 system but verified against a fresh built 5.3.3 with no 
additions.

Verified. I don't have time to look into this further today (or
likely this week), but valgrind on a current 5.3 build shows a loss
record demonstrating this:

==19168== 130,800 (11,200 direct, 119,600 indirect) bytes in 100 blocks are 
definitely lost in loss record 28 of 28
==19168==    at 0x4C27480: calloc (vg_replace_malloc.c:467)
==19168==    by 0x471A5F: timelib_tzinfo_ctor (timelib.c:108)
==19168==    by 0x471317: timelib_parse_tzfile (parse_tz.c:318)
==19168==    by 0x442F99: timelib_get_zone (parse_date.re:807)
==19168==    by 0x444520: scan (parse_date.re:1641)
==19168==    by 0x46ED0E: timelib_strtotime (parse_date.re:1795)
==19168==    by 0x435879: zif_strtotime (php_date.c:1427)
==19168==    by 0x9E5022: execute_internal (zend_execute.c:1261)
==19168==    by 0xBEA2D38: xdebug_execute_internal (xdebug.c:1335)
==19168==    by 0x9E6057: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:318)
==19168==    by 0x9EA9A7: ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(zend_vm_execute.h:1606)
==19168==    by 0x9E53E1: execute (zend_vm_execute.h:107)

Timezone identifier parsing initiated by the timelib is not tracked by the caching mechanism of php_date_parse_tzfile and ends up leaked.

The illustrate this, running php -d date.timezone="Europe/Lisbon" -r "echo strtotime('Monday 00:00 Europe/Paris');"

gives these distinct backtraces in one of the functions were leaked memory is allocated:

#0  read_transistions (tzf=0x7fff5facace0, tz=0x7fbbace67fe8)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_tz.c:86
#1  0x0000000000459563 in timelib_parse_tzfile (
    timezone=0x27f7ee0 "Europe/Lisbon", tzdb=0x8558a0)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_tz.c:322
#2  0x00000000004215ef in php_date_parse_tzfile (
    formal_tzname=0x27f7ee0 "Europe/Lisbon", tzdb=0x8558a0)
    at /home/glopes/php/php-trunk/ext/date/php_date.c:829
#3  0x0000000000421923 in get_timezone_info ()
    at /home/glopes/php/php-trunk/ext/date/php_date.c:939
#4  0x0000000000423ed8 in zif_strtotime (ht=1, return_value=0x7fbbace65e40,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/glopes/php/php-trunk/ext/date/php_date.c:1396


#0  read_transistions (tzf=0x7fff5facab10, tz=0x7fbbace68858)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_tz.c:86
#1  0x0000000000459563 in timelib_parse_tzfile (
    timezone=0x7fbbace687f0 "Europe/Paris", tzdb=0x8558a0)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_tz.c:322
#2  0x0000000000431c37 in timelib_get_zone (ptr=0x7fff5facac40,
    dst=0x7fbbace685d8, t=0x7fbbace68588, tz_not_found=0x7fff5facac3c,
    tzdb=0x8558a0) at /home/glopes/php/php-trunk/ext/date/lib/parse_date.c:808
#3  0x0000000000431f90 in scan (s=0x7fff5facad00)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_date.c:1009
#4  0x0000000000456f07 in timelib_strtotime (
    s=0x7fbba90ed708 "Monday 00:00 Europe/Paris", len=25,
    errors=0x7fff5facadd8, tzdb=0x8558a0)
    at /home/glopes/php/php-trunk/ext/date/lib/parse_date.c:24690
#5  0x00000000004240f9 in zif_strtotime (ht=1, return_value=0x7fbbace65e40,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/glopes/php/php-trunk/ext/date/php_date.c:1426

Hmm, I suspected this would be the issue. It's going to be a bit tricky to solve.

I can also reproduce it with:

for($i=0;$i<100000;++$i) {
	new DateTime('UTC');
}

This just took our entire production environment to its knees. This, even in a 
non-daemon program, can be quickly fatal with enough requests.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.