|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70864 new DateTime in __construct() crashes
Submitted: 2015-11-05 20:34 UTC Modified: 2015-11-06 20:50 UTC
From: eric at ericstern dot com Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 7.0.0RC6 OS: Centos 7
Private report: No CVE-ID: None
 [2015-11-05 20:34 UTC] eric at ericstern dot com
Instantiating a DateTime object in a constructor causes an engine crash, printing either "Segmentation Fault" or "zend_mm_heap corrupted".

This only seems to happen in Centos7 with PHP7RC6 installed from the Webtatic-Testing repo; I can NOT reproduce it on OS X using the same version installed via homebrew. In that environment, I have disabled all extensions by renaming /etc/php.d to /etc/php.d.disabled and the crash still occurs.

Originally found under nginx/php-fpm, but happens under cli as well.

I can privately provide access to the server which reproduces this if helpful.

Test script:
class X {
  private $date;
  public function __construct() {
    $this->date = new DateTime();
$x = new X();

Expected result:
object(X)#1 (1) {
  object(DateTime)#2 (3) {
    string(26) "2015-11-05 20:24:38.000000"
    string(3) "UTC"

(exit 0)

Actual result:
object(X)#1 (1) {
  object(DateTime)#2 (3) {
    string(26) "2015-11-05 20:31:09.000000"
    string(3) "UTC"
Segmentation fault

(exit 139)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-11-05 20:39 UTC] eric at ericstern dot com
Update - this doesn't even need to be in an object's constructor, as I initially discovered it. Simply `<?php new DateTime();` will reproduce the issue!
 [2015-11-05 21:54 UTC] fabian at tag1consulting dot com
FWIW: The test script works for me on latest PHP-7.0 git checkout.
 [2015-11-05 21:56 UTC] fabian at tag1consulting dot com
Note: I tested it on Ubuntu. I did miss that its only crashing on Centos 7.
 [2015-11-06 08:40 UTC]
-Status: Open +Status: Feedback
 [2015-11-06 08:40 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

 [2015-11-06 19:38 UTC]
Unable to reproduce on Debian plus it is valgrind-clean. It sounds like it is related to the distro-specific patches that I know RedHat/Centos do to support the system tz lib. You could help us verify that by building from our source on that box and testing a non-modified build.
 [2015-11-06 19:50 UTC] eric at ericstern dot com
-Status: Feedback +Status: Open
 [2015-11-06 19:50 UTC] eric at ericstern dot com
Lawrence, here you go:

[root@ansi-test public]# gdb /usr/bin/php /tmp/core-php.26904
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /usr/bin/php...Reading symbols from /usr/bin/php...(no debugging symbols found)...done.
(no debugging symbols found)...done.
[New LWP 26904]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/".
Core was generated by `php crash.php'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fdbfe83ee7a in _efree ()
Missing separate debuginfos, use: debuginfo-install php70w-cli-7.0.0-0.14.RC6.w7.x86_64
(gdb) bt
#0  0x00007fdbfe83ee7a in _efree ()
#1  0x00007fdbfe6cc717 in timelib_tzinfo_dtor ()
#2  0x00007fdbfe872402 in zend_hash_destroy ()
#3  0x00007fdbfe6a1c81 in zm_deactivate_date ()
#4  0x00007fdbfe868094 in zend_deactivate_modules ()
#5  0x00007fdbfe801d8d in php_request_shutdown ()
#6  0x00007fdbfe8e9f68 in do_cli ()
#7  0x00007fdbfe6a1a4a in main ()

Rasmus - I'll look into doing a source build shortly and update this.
 [2015-11-06 20:37 UTC]
This is the same issue as It's not a bug in PHP, it's a bug in a patch used by your package provider. Could you please report this to Webtatic?
 [2015-11-06 20:50 UTC] eric at ericstern dot com
-Status: Open +Status: Closed
 [2015-11-06 20:50 UTC] eric at ericstern dot com
Send the maintainer an email with a bunch of related links. Also confirmed at the command line that `USE_ZEND_ALLOC=0 php crash.php` prevents the issue, as the linked bug suggested. Thanks for the help :)
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Apr 08 16:01:25 2020 UTC