php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67118 DateTime constructor crash with invalid data
Submitted: 2014-04-23 14:51 UTC Modified: 2014-08-25 00:21 UTC
From: per at interapp dot se Assigned: ab (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.5.11 OS: Windows 2008 R2
Private report: No CVE-ID: None
 [2014-04-23 14:51 UTC] per at interapp dot se
Description:
------------
Hello,

Running Drupal 7 on a IIS 7 web server with the latest php 5.5.11.

Regularly php-cgi crashes. Have collected a dump using the instructions on php.net.

Crash dump available on:
http://blogg.jag.se/crash_dump1.zip

DetailID = 1
	Count:    1
	Exception #:  0XC0000005
	Stack:        
		
		php5!fetch_timezone_offset
		php5!timelib_get_time_zone_info
		php5!date_format
		php5!zif_date_format
		php5!zend_do_fcall_common_helper_SPEC
		php5!execute_ex
		php5!zend_call_function
		php5!zif_call_user_func_array
		php5!zend_do_fcall_common_helper_SPEC
		php5!execute_ex
		php5!zend_call_function
		php5!zif_call_user_func_array
		php5!zend_do_fcall_common_helper_SPEC
		php5!execute_ex
		php5!zend_execute
		php5!zend_execute_scripts
		php5!php_execute_script
		WARNING: Frame IP not in any known module. Following frames may be wrong.
		0x0
		MSVCR110!getenv
		MSVCR110!mbtowc
		MSVCR110!_getmainargs
		php_cgi!pre_cpp_init

Best Regards

Eric

Expected result:
----------------
Regularly the page crashes instead of showing the result, this can be any page on the website.

Actual result:
--------------
The php-cgi process crashes.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-23 14:52 UTC] per at interapp dot se
php 5.5.11 NTS
 [2014-04-23 15:11 UTC] per at interapp dot se
Report from the dump file:

http://blogg.jag.se/crash_dump1.mht
 [2014-04-23 23:16 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2014-04-23 23:16 UTC] ab@php.net
hi,

could you please disable opcache and try again?

The dump complains there was no debug symbols, could you please get some (the corresponding debug pack is downloadable from windows.php.net)? also, it namely wasn't in the dump, but just to be sure - you don't use xdebug or similar together with opcache?

Thanks.
 [2014-04-24 06:41 UTC] per at interapp dot se
-Status: Feedback +Status: Open
 [2014-04-24 06:41 UTC] per at interapp dot se
Hi,

Opcache disabled, appears it is still crashing intermittently.

Quite sure I followed the instructions to get the dump with symbols using Debug Diagnostic Tool v2.0.

Will try again and upload the result.
 [2014-04-24 06:58 UTC] per at interapp dot se
Not using xdebug in this environment.

New crash report (I think symbols should be in this one):

http://blogg.jag.se/crash_report2.mht
 [2014-04-24 10:09 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2014-04-24 10:09 UTC] ab@php.net
Thanks for the new dump. So no opcache, symbols are there, the backtrace is the same. Actually we run quite some tests for drupal http://131.107.220.66/PFTT-Results/PHP_5_5/rb8d0294/ , but there are no crashes so far. Sadly there are no function arguments/values in the backtrace.

Now may I ask you whether it is reproducable with just the standard setup. If not, what does one need? Maybe you could isolate an issue if you use some additional modules. Maybe it were possible to make your drupal+db available?

Maybe, if it's your own code causing it, you could extract some small snippet? Looks like we need some reproduce code to step forward. As a hint here - it is some code calling date_format() passed to call_user_func_array(), so a call could look like call_user_func_array('date_format', array(.....)).

Thanks.
 [2014-04-24 12:20 UTC] per at interapp dot se
It appears it's the Cron functionality of Drupal causing this. Installed the Cron Debug module to run cron tasks for modules individually. It almost always fails when running the cron job for the search module:

http://domain/admin/config/system/cron/debug/run/search

Will try to narrow this down even further.
 [2014-04-24 19:39 UTC] per at interapp dot se
Hi,

We now know that the last line called before crashing is:

date_format($date, DATE_FORMAT_DATETIME);

Where bin2hex($date) evaulates to 20.

We can however not reproduce this by again running:

date_format(hex2bin(20), "Y-m-d H:i:s");

But we can reproduce it by using the $date variable in the code.

Do you guys have any ideas on how to proceed from here?

Best Regards

Eric
 [2014-04-24 20:01 UTC] per at interapp dot se
To reproduce you need the Drupal contrib module Date installed in the sites/all/modules:
https://drupal.org/project/date

Occurs in file /sites/all/modules/date/date.module:235.

You probably also need a content type with a date field on it, and some crappy data.

BR

Eric
 [2014-04-24 21:07 UTC] per at interapp dot se
Hi,

We can reproduce it every time with the following 2 php files, both through php-cgi as well as on the command line:

http://blogg.jag.se/php5bug.zip

Best Regards

Eric
 [2014-04-25 00:05 UTC] ab@php.net
-Assigned To: +Assigned To: ab
 [2014-04-25 09:08 UTC] per at interapp dot se
-Status: Feedback +Status: Assigned
 [2014-04-25 09:08 UTC] per at interapp dot se
Appears to also be reproducible on 5.2.17 and 5.3.28.

BR Eric
 [2014-04-25 11:55 UTC] per at interapp dot se
Hi,

Can we help somehow with this issue? Or a possible workaround?

BR

Eric
 [2014-04-25 12:00 UTC] ab@php.net
Eric,

I'm on it right now working on a fix. Man, i have to say you did a fantastic job chasing that down no a couple of files! So no worries, the fix is on the way.

Cheers.
 [2014-04-25 15:24 UTC] ab@php.net
-Summary: php-cgi crashes regularly on IIS 7 +Summary: DateTime constructor crash with invalid data
 [2014-04-25 15:28 UTC] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 [2014-04-25 15:28 UTC] ab@php.net
-Status: Assigned +Status: Closed
 [2014-04-25 16:43 UTC] ab@php.net
Eric,

the fix applied to 5.4+, 5.2 is dead anyway and 5.3 gets only security fixes. You can bridge the time until the next release with this http://windows.php.net/downloads/snaps/php-5.5/r46344b1/ or any later snap.

And once more - thanks for the great job in triaging the buggy code.
 [2014-04-25 23:25 UTC] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 [2014-04-25 23:29 UTC] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 [2014-04-28 11:18 UTC] per at interapp dot se
Hi Anatol,

Thanks a lot for the fix. It is applied in production now and everything is working great. Actually we didn't believe we would be able to provide you with a code snippet for reproduction either :)

Thanks once again

BR Eric
 [2014-05-01 14:59 UTC] tyrael@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 [2014-06-06 08:15 UTC] arjen at react dot com
Regression was reported in https://bugs.php.net/bug.php?id=67179
Which can be closed now...
 [2014-06-06 23:36 UTC] slusarz at curecanti dot org
See: http://lists.horde.org/archives/dev/Week-of-Mon-20140602/028641.html

In short: After these fixes

http://git.php.net/?p=php-src.git;a=commit;h=1fe9f1e4f572d7b4d5a3872f41ea61e71fb563bf
http://git.php.net/?p=php-src.git;a=commit;h=15d8c80ead75be976c18a66b0933cf52f3e6579f

I believe the behavior is correct.

However, these temporary fixes were reverted in master.  See:

http://git.php.net/?p=php-src.git;a=commit;h=f11f7f56013c5ee4e6009997602e9b5a64064909

As described in the e-mail linked above, this returns to incorrect behavior because it causes DateTime to act entirely different from every other class when an exception is thrown in the constructor.  A class that extends a constructor should be allowed to do whatever is necessary to try to fix the issue and should not artificially be disallowed from accessing itself because of an exception below it.
 [2014-08-25 00:21 UTC] datibbaw@php.net
This commit seems to have fixed the behaviour again:

http://git.php.net/?p=php-src.git;a=commit;h=c749fe2067d29615df250e59c9a891a63dcc7e7f

According to this code:

  class C extends DateTime {
     public function __construct($time = null, $timezone = null)
     {
         try {
             parent::__construct('XXXX');
             return;
         } catch (Exception $e) {}

         if (is_null($this)) {
             print "THIS IS NULL\n";
         } else {
             print "THIS STILL EXISTS\n";
         }
     }
  }

  new C();

This now outputs: THIS STILL EXISTS
 [2014-10-07 23:15 UTC] stas@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src-security.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 [2014-10-07 23:26 UTC] stas@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src-security.git;a=commit;h=c1aa9baf29d1a20fa60c1cef3979a80014f6677b
Log: Fixed bug #67118 DateTime constructor crash with invalid data
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Oct 08 15:01:27 2024 UTC