Bug #72011 [Com]: DateTime serializes as empty object

From: Date: Tue, 14 Jun 2016 20:11:31 +0000
Subject: Bug #72011 [Com]: DateTime serializes as empty object
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-201619@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72011&edit=1

 ID:                 72011
 Comment by:         bill at zeroedin dot com
 Reported by:        benjamin dot roth at jaumo dot com
 Summary:            DateTime serializes as empty object
 Status:             Open
 Type:               Bug
 Package:            Date/time related
 Operating System:   Linux
 PHP Version:        7.0.5
 Block user comment: N
 Private report:     N

 New Comment:

Actually yes, this bug has consistently appeared after a maximum execution time or allowed memory
exhaustion bailout. After increasing the timeout in our dev environment, the bug has not reappeared,
but I haven't tested the allowed memory ceiling yet.


Previous Comments:
------------------------------------------------------------------------
[2016-06-14 19:39:02] nikic@php.net

Going out on a limb here ... this might be happening because serialize() is called while
gc_active=1. The DateTime get_properties handler contains a check that will return an empty
properties HT in that case. What's not clear here is how serialize() could be called while
gc_active=1. My guess would be that somehow a fatal error is triggered during GC, causing a bailout
without resetting the flag. This would be consistent with following requests experiencing the same
issue, as the flag would stay enabled.

Do any of see fatal errors (e.g. due to timeout, memory limit, OOM) in your logs around the time
this issue starts to occur?

Even if this should be totally unrelated, we should still drop those gc_active checks ... they
aren't necessary as long as everything defines a proper get_gc handler.

------------------------------------------------------------------------
[2016-06-14 19:16:41] benjamin dot roth at jaumo dot com

In my case (PHP7) it is with opcache:

zend_extension=opcache.so

opcache.optimization_level=0xffffffff

----

PHP 7.0.5-2+deb.sury.org~trusty+1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

------------------------------------------------------------------------
[2016-06-14 19:10:26] bill at zeroedin dot com

This is with opcache in my case.

------------------------------------------------------------------------
[2016-06-14 19:00:21] derick@php.net

Is this with or without opcache?

------------------------------------------------------------------------
[2016-06-14 17:11:39] bill at zeroedin dot com

I have also seen this problem. I am running php-fpm 5.6.22-1+donate.sury.org~trusty+1 via nginx
inside a docker container. Under periods of unusually high load, it seems one or more php-fpm
processes will begin exhibiting this broken serialization behavior. From the time the bug is first
triggered until php-fpm is restarted, some requests will show the bad behavior, and some will not. 

I have put some extra logic in our app caching logic to prevent tainting the cache pool with bad
serialized DateTime data, but this seems like a rather critical bug. Since PHP is not outright
crashing, data processed by bugged php-fpm workers could conceivably bring down or corrupt large
applications. In our experience, it brought down our prod site until the worker pools could be
recycled.

I have noticed that this issue has only occurred for us between 3-5pm EST. I don't know if that
matters at all, but this is a heisenbug, so it might be relevant.

------------------------------------------------------------------------


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=72011


--
Edit this bug report at https://bugs.php.net/bug.php?id=72011&edit=1


Thread (19 messages)

« previous php.bugs (#201619) next »