Edit report at https://bugs.php.net/bug.php?id=53502&edit=1
ID: 53502 Updated by: der...@php.net Reported by: jsheridan at tenable dot com Summary: strtotime with timezone memory leak -Status: Verified +Status: Closed Type: Bug Package: Date/time related Operating System: Redhat ES5 PHP Version: 5.3.3 Assigned To: derick Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2011-12-06 06:20:52] der...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=320481 Log: - Fixed bug #53502 (strtotime with timezone memory leak). - Fixed bug #52062 (large timestamps with DateTime::getTimestamp and DateTime::setTimestamp). - Fixed bug #51994 (date_parse_from_format is parsing invalid date using 'yz' format). - Fixed bug #51223 (Seg fault while creating (by unserialization) DatePeriod). ------------------------------------------------------------------------ [2011-04-08 21:53:27] dr dot ductus at gmail dot com This just took our entire production environment to its knees. This, even in a non-daemon program, can be quickly fatal with enough requests. ------------------------------------------------------------------------ [2011-04-08 21:52:55] jstephens at qualtrics dot com I can also reproduce it with: for($i=0;$i<100000;++$i) { new DateTime('UTC'); } ------------------------------------------------------------------------ [2010-12-12 18:01:58] der...@php.net Hmm, I suspected this would be the issue. It's going to be a bit tricky to solve. ------------------------------------------------------------------------ [2010-12-12 10:33:09] cataphr...@php.net 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53502 -- Edit this bug report at https://bugs.php.net/bug.php?id=53502&edit=1
