ID: 48752 Updated by: srina...@php.net Reported By: theta...@php.net -Status: Closed +Status: Open Bug Type: Date/time related Operating System: * (ZTS build only!) PHP Version: 5.*, 6 Assigned To: pajoye New Comment:
the fix for this issue has been rolled back. http://svn.php.net/viewvc/?view=revision&revision=289991 [srir...@sriramn]'PHP_5_2'>svn diff -r 289982:289991 ext/date/php_date.c Index: ext/date/php_date.c =================================================================== --- ext/date/php_date.c (revision 289982) +++ ext/date/php_date.c (revision 289991) @@ -371,7 +371,6 @@ } DATEG(timezone) = NULL; DATEG(tzcache) = NULL; - DATEG(last_errors) = NULL; return SUCCESS; } @@ -389,10 +388,6 @@ FREE_HASHTABLE(DATEG(tzcache)); DATEG(tzcache) = NULL; } - if (DATEG(last_errors)) { - timelib_error_container_dtor(DATEG(last_errors)); - DATEG(last_errors) = NULL; - } return SUCCESS; } accordingly, this bug has been moved to open status. The corresponding NEWS entry for this bug will also need to be rolled back as well. Previous Comments: ------------------------------------------------------------------------ [2009-10-27 10:45:19] paj...@php.net 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/. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2009-10-27 10:44:12] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289982 Log: - #48752 ------------------------------------------------------------------------ [2009-10-27 10:41:45] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289981 Log: - #48752, crash during date parsing with invalid date ------------------------------------------------------------------------ [2009-10-24 23:36:59] paj...@php.net here is a patch: http://pastie.org/668460 It makes the last_errors request specific as well as it should be. However the problem is not completely solved as we need a lock before the 1st operation on last_errors until we are done. It is not sufficent to lock it before calling a function or setting it a value. Other threads may affect it during two calls. I consider this last_errors as a design mistake, but if you like to keep it this way then we will need this global lock. ------------------------------------------------------------------------ [2009-10-24 22:52:41] paj...@php.net Simply script: $datetime_object = date_create("d"); with the timezone set in php.ini. The crashes occur only with an invalid date. For some reason the global last_errors is not NULL anymore (but it is set to NULL during MINIT) but freed somewhere. By the way, I do not understand the need to store the warning in a GLOBALS (for all applications running on the same server) when we work with object. That's a design flaw as other applications using the same API at the same time may generate warnings, defeating the whole point of the warnings (if they did not crash php before). That could affect NTS server as well. ------------------------------------------------------------------------ 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 http://bugs.php.net/48752 -- Edit this bug report at http://bugs.php.net/?id=48752&edit=1
