php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #70688 new DateTime object produces Segmentation fault or zend_mm_heap corrupted
Submitted: 2015-10-11 01:44 UTC Modified: 2015-10-18 15:49 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: jerome at taotesting dot com Assigned: dmitry (profile)
Status: Closed Package: Date/time related
PHP Version: 7.0.0RC5 OS: 3.19.0-30-generic 14.04 Ubuntu
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jerome at taotesting dot com
New email:
PHP Version: OS:

 

 [2015-10-11 01:44 UTC] jerome at taotesting dot com 
Description:
------------
Dear PHP Team,

When instantiating a DateTime object with PHP 7.0.0RC4 using PHP CLI, the output systematically contains "zend_mm_heap corrupted" OR "Segmentation fault (core dumped)".

I'm using the PHP 7.0.0RC4 package provided by ondrej (ppa:ondrej/php-7.0) for Ubuntu. In addition with the following test script, expected output and actual output, I must say that calling

date_default_timezone_set('Europe/Brussels');

does not help either.

Thanks for fixing it, as we are waiting PHP7.0.0 as the messiah :) !
Thanks a lot also for all your efforts for making PHP better every day!

All the best,
Jérôme Bogaerts



Test script:
---------------
<?php
$date = new \DateTime('2000-01-01');
echo $date->format('Y-m-d') . "\n";

Expected result:
----------------
// -- Expected output is simple as:
2000-01-01


Actual result:
--------------
// -- Output when php.ini's directive date.timezone is commented (using ;)
2000-01-01
zend_mm_heap corrupted
// OR (randomly)
2000-01-01
Segmentation fault (core dumped)


// -- Output when php.ini's directive date.timezone = Europe/Brussels
2000-01-01
zend_mm_heap corrupted
// OR (randomly)
2000-01-01
Segmentation fault (core dumped)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-10-11 01:50 UTC] jerome at taotesting dot com
-Operating System: 3.19.0-30-generic #34~14.04.1-Ub +Operating System: 3.19.0-30-generic 14.04 Ubuntu
 [2015-10-11 01:50 UTC] jerome at taotesting dot com 
More readable OS version edited.
 [2015-10-11 13:54 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2015-10-11 13:54 UTC] felipe@php.net 
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
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php 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-10-11 17:02 UTC] jerome at taotesting dot com
-Status: Feedback +Status: Open
 [2015-10-11 17:02 UTC] jerome at taotesting dot com 
Please find below the backtrace:

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-linux-gnu".
Reading symbols from /usr/bin/php7.0...(no debugging symbols found)...done.

[New LWP 2170]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `php date.php'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000075aa3a in _efree ()
(gdb) bt
#0  0x000000000075aa3a in _efree ()
#1  0x00000000004a1107 in timelib_tzinfo_dtor ()
#2  0x000000000078b962 in zend_hash_destroy ()
#3  0x000000000047729c in zm_deactivate_date ()
#4  0x0000000000781e24 in zend_deactivate_modules ()
#5  0x000000000071ee45 in php_request_shutdown ()
#6  0x0000000000801262 in ?? ()
#7  0x00000000004770a0 in main ()
 [2015-10-12 09:23 UTC] derick@php.net
-Assigned To: +Assigned To: dmitry
 [2015-10-12 09:23 UTC] derick@php.net 
Dmitry, I think this is related to your memory management macros.
 [2015-10-12 09:43 UTC] dmitry@php.net 
I can't reproduce the crash or see any related issues using valgrind.
 [2015-10-12 09:54 UTC] jerome at taotesting dot com 
Hello there!

Did you test in RC4? This is where it fails.

Actually, in Travis-CI worker, this does not break. It seems they use "PHP 7.0.0-dev (cli) (built: Oct 10 2015 22:48:00) ( ZTS )"

Does that mean this is already solved on the current development branch ;) ?

Jérôme Bogaerts
 [2015-10-12 10:27 UTC] dmitry@php.net 
I use latest development version.
anyway, the bug (if any) most probably couldn't be fixed after RC4.
This behavior is tested by few tests.

I suspect, something may be wrong with your build or configuration or unsupported extensions.

Can you repeat the problem running `php -n` (without php.ini)?
 [2015-10-12 10:59 UTC] jerome at taotesting dot com 
The error occurs also with php -n.

I will contact the provider of the package (Ondrej)

Thanks!
 [2015-10-12 11:02 UTC] jerome at taotesting dot com 
Actually, a similar issue was already reported at https://github.com/oerdnj/deb.sury.org/issues/123. This is the issue tracker of the package maintainer.
 [2015-10-17 15:04 UTC] jerome at taotesting dot com 
Hello there,

Still under investigation on Ondrej's issue tracker, as it still happens in PHP7-RC5 in Unbuntu.

See 

https://github.com/oerdnj/deb.sury.org/issues/128
https://github.com/oerdnj/deb.sury.org/issues/129
https://github.com/oerdnj/deb.sury.org/issues/123
 [2015-10-17 15:12 UTC] jerome at taotesting dot com
-PHP Version: 7.0.0RC4 +PHP Version: 7.0.0RC5
 [2015-10-17 15:12 UTC] jerome at taotesting dot com 
Changed PHP Version from 7.0.0RC4 to 7.0.0RC5.
 [2015-10-17 15:59 UTC] jerome at taotesting dot com 
Hi guys !

Running the test script (date.php) with USE_ZEND_ALLOC=0 makes the error to disappear!

USE_ZEND_ALLOC=0 php date.php 

Output is systematically correct then.
 [2015-10-17 16:03 UTC] jerome at taotesting dot com 
Please find more information on this USE_ZEND_ALLOC=0 clue at 

https://github.com/oerdnj/deb.sury.org/issues/128#issuecomment-148925641
 [2015-10-18 15:49 UTC] nikic@php.net
-Status: Assigned +Status: Closed
 [2015-10-18 15:49 UTC] nikic@php.net 
This issue has been fixed downstream, see https://github.com/oerdnj/deb.sury.org/issues/128. The next RC5 build should work.
 [2015-11-03 13:16 UTC] mihor dot cz at gmail dot com 
Hello PHP developers,
This bug is hitting me even with PHP 7.0 RC6 (RC5 and RC4 too, RC3 NOT)

I'm using CentOS 6.6 and CentOS 7.1.1503 (with both systems I'm experiencing same bug)

So what should I do?
Setting USE_ZEND_ALLOC=0 on every server does not look like a good solution to me.

Nikic
What does it mean exactly: "This issue has been fixed downstream" ?

Thank you very much
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Nov 24 03:01:32 2024 UTC