php 5.5.11 NTS

Report from the dump file:

http://blogg.jag.se/crash_dump1.mht

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.

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.

Not using xdebug in this environment.

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

http://blogg.jag.se/crash_report2.mht

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.

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.

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

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

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

Appears to also be reproducible on 5.2.17 and 5.3.28.

BR Eric

Hi,

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

BR

Eric

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.

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.

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

This introduce a regression in some code.

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

Regression was reported in https://bugs.php.net/bug.php?id=67179
Which can be closed now...

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.

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