Edit report at https://bugs.php.net/bug.php?id=80376&edit=1
ID: 80376
Updated by: requinix@php.net
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:
Go ahead and get the backtrace anyway. It might not have as much useful information, but it's
better than nothing.
Previous Comments:
------------------------------------------------------------------------
[2020-11-22 09:03:33] mav2287 at aol dot com
I was able to get GDB installed and I was able to get both 7.3 and 7.4 re-compiled with
--enable-debug so that I could use GDB. That is when things got interesting or annoying depending on
how you look at it. The bug was not present and I couldn't replicate it after compiling with
--enable-debug as a sanity check I compiled both again with it and sure enough the bug was back. Any
ideas how to get a backtrace since the bug doesn't show up when the --enable-debug flag is set?
------------------------------------------------------------------------
[2020-11-22 05:55:54] requinix@php.net
No. Xdebug provides a backtrace of PHP code, but what we need here is a backtrace of PHP's own
internals.
I don't know Macs well, but if you can install gdb then using it is pretty simple:
1. Put the PHP code into a file so you can execute it more easily
2. Start gdb by telling it to load PHP (as in the program)
3. Have it run PHP, passing an argument of the file name so PHP will run the file
4. Let it run for a couple seconds so that it's definitely hung somewhere
5. Interrupt PHP with... Cmd+C? Or maybe Ctrl+C.
6. Have gdb create a backtrace with the bt command
Basically, your terminal window will probably end up looking something like
> gdb /path/to/php
(gdb loads)
> (gdb) run /path/to/file.php
(no output while php hangs)
Cmd+C
> (gdb) bt
(backtrace output)
Take a look at the output, see if it appears like it might be useful, and post it. Ideally you would
use a debug build of PHP for this, which includes more information than regular builds do, but with
some luck that won't be necessary.
For bonus points, repeat that process a few times, and compare the backtraces to see what is and
isn't common between them.
------------------------------------------------------------------------
[2020-11-22 01:57:08] mav2287 at aol dot com
Haven't done a debug backtrace like that before and don't have gdb on that system is this
something I can do with Xdebug?
------------------------------------------------------------------------
[2020-11-17 21:30:44] requinix@php.net
Unless someone else can reproduce this (I couldn't on Linux),
Can you try running PHP with gdb or another debugger attached, run the code to the point it hangs,
interrupt PHP so you return to the debugger, and get a backtrace? Hopefully that will help identify
what sort of loop is involved.
------------------------------------------------------------------------
[2020-11-17 19:41:20] mav2287 at aol dot com
In case it isn't clear when using the sample script once you execute "$newDate =
$date->modify('last day of this month');" PHP will hang. You will never get the
chance to go to the next step of the script and do "php > var_dump($newDate);" as the
object is never created,
------------------------------------------------------------------------
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