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

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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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