Bug #80376 [Csd]: last day of the month causes runway cpu usage

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: Closed Type: Bug Package: Date/time related Operating System: OS X 10.11.6 El Capitan PHP Version: 7.4.12 -Assigned To: +Assigned To: derick Block user comment: N Private report: N New Comment: The fix for this bug has been committed. If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test. Thank you for the report, and for helping us make PHP better. I've regenerated the parsers for ext/date. Previous Comments: ------------------------------------------------------------------------ [2020-12-21 10:32:31] derick@php.net Automatic comment on behalf of github@derickrethans.nl Revision: http://git.php.net/?p=php-src.git;a=commit;h=288332077fa22b78afda1951a357444a901a9da9 Log: Fixed bug #80376 (last day of the month causes runway cpu usage) ------------------------------------------------------------------------ [2020-12-21 10:32:30] derick@php.net 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) ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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