Edit report at https://bugs.php.net/bug.php?id=80376&edit=1
ID: 80376
Updated by: derick@php.net
Reported by: mav2287 at aol dot com
Summary: last day of the month causes runway cpu usage
-Status: Open
+Status: Closed
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:
Automatic comment on behalf of github@derickrethans.nl
Revision: http://git.php.net/?p=php-src.git;a=commit;h=b043759cb42b33e02359ca1c30d8d5b68d8a015e
Log: Fixed bug #80376 (last day of the month causes runway cpu usage)
Previous Comments:
------------------------------------------------------------------------
[2020-12-19 15:41:39] php-bugs-2020 at ryandesign dot com
After installing and testing several versions of Apple Clang, I've found that the broken
versions are Apple LLVM version 7.3.0 (clang-703.0.29) (which came with Xcode 7.3) through Apple
LLVM version 8.0.0 (clang-800.0.42.1) (which came with Xcode 8.1/8.2/8.2.1) inclusive.
Apple LLVM version 7.0.2 (clang-700.1.81) (which came with Xcode 7.2.1) and earlier work fine, and
Apple LLVM version 8.1.0 (clang-802.0.38) (which came with Xcode 8.3) and later work fine.
There are several other parsers in php that were generated by re2c 0.16 or later. I wonder if any of
those functions might also be affected by hangs when compiled by an affected compiler.
./Zend/zend_ini_scanner.c:/* Generated by re2c 1.0.1 */
./Zend/zend_ini_scanner_defs.h:/* Generated by re2c 1.0.1 */
./Zend/zend_language_scanner.c:/* Generated by re2c 1.0.1 */
./Zend/zend_language_scanner_defs.h:/* Generated by re2c 1.0.1 */
./ext/date/lib/parse_date.c:/* Generated by re2c 2.0.3 on Mon Aug 31 12:21:15 2020 */
./ext/date/lib/parse_iso_intervals.c:/* Generated by re2c 2.0.3 on Mon Aug 31 12:21:19 2020 */
./ext/json/json_scanner.c:/* Generated by re2c 1.0.1 */
./ext/json/php_json_scanner_defs.h:/* Generated by re2c 1.0.1 */
./ext/standard/url_scanner_ex.c:/* Generated by re2c 1.0.1 */
./ext/standard/var_unserializer.c:/* Generated by re2c 1.0.1 */
./sapi/phpdbg/phpdbg_lexer.c:/* Generated by re2c 1.0.1 */
------------------------------------------------------------------------
[2020-12-19 14:39:33] php-bugs-2020 at ryandesign dot com
This problem has bitten PHP before. See this re2c bug report from 2016 after 0.16 was released and
PHP regenerated timelib with it:
https://github.com/skvadrik/re2c/issues/154
There, the developer of re2c says it is a bug in clang which evidently was fixed at some point. That
report was with Apple LLVM version 7.3.0 (clang-703.0.29), this issue now is with Apple LLVM version
8.0.0 (clang-800.0.42.1), and we do not see the problem with Apple LLVM version 9.0.0
(clang-900.0.39.2).
PHP previously fixed it by regenerating with re2c 0.13.5:
https://github.com/php/php-src/commit/90c26fb6b102d68a90a519eacec095265d6ba100
and then a few days later regenerating with 0.15.3:
https://github.com/php/php-src/commit/da3995852edf1a5b7b4c8bda7a1e804cb263dc5e
------------------------------------------------------------------------
[2020-12-19 13:52:32] php-bugs-2020 at ryandesign dot com
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
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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