Edit report at https://bugs.php.net/bug.php?id=80376&edit=1
ID: 80376
Comment by: php-bugs-2020 at ryandesign dot com
Reported by: mav2287 at aol dot com
Summary: last day of the month causes runway cpu usage
Status: Open
Type: Bug
Package: Date/time related
Operating System: OS X 10.11.6 El Capitan
PHP Version: 7.4.12
Block user comment: N
Private report: N
New Comment:
The problem is not due to a change in timelib; it's due to the version of re2c that was used to
generate timelib's parse_date.c and parse_iso_intervals.c when it was added to php. When
timelib 2018.03 was added to php, re2c 0.15.3 was used. When 2018.04 was added to php, re2c 2.0.3
was used. If I regenerate with re2c 0.15.3, then I get a working php, even with timelib 2018.04. If
I regenerate with re2c 0.16 or later, then I get a non-working php.
So the simplest fix for now which I recommend the php developers use is to regenerate with re2c
0.15.3.
It would require more investigation to determine whether this is a bug in re2c 0.16 or later or a
bug in how timelib is using re2c. The changelog entry for re2c 0.16 suggests that there have been
dramatic changes to how the c files are generated and that the correctness of the changes could not
be verified manually, so it seems possible that the automatic verification they used wasn't
fully correct or did not cover all cases.
http://re2c.org/releases/release_notes.html#release-0-16
Previous Comments:
------------------------------------------------------------------------
[2020-12-19 12:14:58] php-comment-2020 at ryandesign dot com
Thanks to git bisect, I was able to determine that the problem was introduced in this commit:
https://github.com/php/php-src/commit/778902db63b08a5bdcb45287b1e8c6ef5ef60932
(Update timelib to 2018.04)
Unfortunately that's a large commit, so I guess next I need to bisect timelib to find out what
commit between timelib 2018.03 and 2018.04 caused this.
------------------------------------------------------------------------
[2020-12-19 11:52:40] evtukhov08 at gmail dot com
PHP 8 have the same issue with dates on Mac OS 10.11 installed from brew.
------------------------------------------------------------------------
[2020-12-19 10:24:26] php-comment-2020 at ryandesign dot com
In the MacPorts bug report I suggested that it might have to do with the version of the compiler.
mav2287 confirmed that compiling the affected php versions with Apple Clang 800.0.42.1 from Xcode
8.2.1 (the last version compatible with OS X 10.11) produces a php that does not work, while
recompiling with open-source clang 10.0.1 installed by MacPorts produces a php that works. For those
who want to try this, you would use e.g.:
sudo port install clang-10
sudo port -ns upgrade --force php80 configure.compiler=macports-clang-10
This would only recompile the command line php80. Repeat the procedure for php80-apache2handler,
php80-cgi, and/or php80-fpm if you use those SAPIs. Substitute php74, php73, or php72 as needed. We
now have clang-11 in MacPorts so you could presumably use that, or clang-9.0, instead, if desired.
So this suggests that there is some code that was added to php this year that does not get along
with at least Apple Clang 800.0.42.1, though it's not clear which range of Apple Clang versions
are affected.
Perhaps I can git bisect to find which commit introduced the problem.
------------------------------------------------------------------------
[2020-12-17 10:54:38] ekl at woodwing dot com
I did some more digging on the problematic MacOSX 10.11.6 machine.
It seems that between end of March 2020 and early October 2020 there were no PHP 7.3 nor PHP 7.4
patches released by MacPorts:
--------------------------------------------------------
$ git log --grep "php73"
commit 2b90e9dbf0b7c7d330325e724793d1ab6fc0e062
Author: Ryan Schmidt <ryandesign@macports.org>
Date: Fri Oct 2 09:59:49 2020 -0500
php: Update php73 to 7.3.23
commit b03fe0675f1efe520c67b13a6ccc17a6f9a99e09
Author: Ryan Schmidt <ryandesign@macports.org>
Date: Tue Mar 24 07:24:35 2020 -0500
php: Update php73 to 7.3.16
--------------------------------------------------------
$ git log --grep "php74"
commit 2eca46bc0c123000c2ef7efddfd382b411d41dfc
Author: Ryan Schmidt <ryandesign@macports.org>
Date: Thu Oct 1 18:23:45 2020 -0500
php: Update php74 to 7.4.11
commit 1b2546f94ff2583e3727f7f2df19f72386afc22e
Author: Ryan Schmidt <ryandesign@macports.org>
Date: Thu Mar 26 09:30:28 2020 -0500
php: Update php74 to 7.4.4
--------------------------------------------------------
I repeated my test (I mentioned in earlier posts) for all these 4 commits listed above. And it turns
out that:
- 7.3.16 works!
- 7.3.23 hangs!
- 7.4.4 works!
- 7.4.11 hangs!
I hope this helps you pinpointing the problem.
------------------------------------------------------------------------
[2020-12-16 17:32:25] ekl at woodwing dot com
On the problematic 10.11.6 machine, after uninstalling PHP 7.3.25, I managed to bring back the old
PHP 7.3.10 installation as follows:
$ git clone --single-branch https://github.com/macports/macports-ports.git
$ git log --grep "php73 to 7.3.10"
commit 22d4d0a0ba24b20946696eeb887b02e2d15509d5
Author: Ryan Schmidt <ryandesign@macports.org>
Date: Thu Sep 26 19:31:04 2019 -0500
php: Update php73 to 7.3.10
=> Note down the commit number for usage below.
$ cd /Users/your-user-name
$ git checkout 22d4d0a0ba24b20946696eeb887b02e2d15509d5
$ portindex /Users/your-user-name/macports-ports
$ vi /opt/local/etc/macports/sources.conf
=> Add the following line just before the rsync command:
file:///Users/your-user-name/macports-ports [nosync]
$ sudo port install php73 @7.3.10
$ php73 -v
PHP 7.3.10 (cli) (built: Dec 16 2020 17:51:56) ( NTS )
Copyright (c) 1997-2018 The PHP Group
The following test shows that the old PHP 7.3.10 installation has NO problem:
$ php73 -r 'print (new DateTime( "15 Dec 2020" ))->format("Ymd
H:i:s").PHP_EOL;'
20201215 00:00:00
------------------------------------------------------------------------
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=80376
--
Edit this bug report at https://bugs.php.net/bug.php?id=80376&edit=1