PHP 7 error reported when profiling intermediate hook with LSPHP 8.1.24

[redbullpeter]

Bug Report

• [X ] Yes, I reviewed the contribution guidelines.
• [ X] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

My server is setup to use LSPHP for command line PHP.

The command: wp profile hook plugins_loaded:before Results in:

Error: Profiling intermediate hooks is broken in PHP 7, see https://bugs.php.net/bug.php?id=72966

There are no issues profiling non-intermediate hooks.

Describe how other contributors can replicate this bug

Command run in the the root Wordpress folder: wp profile hook plugins_loaded:before

Describe what you would expect as the correct outcome

Expected output is the default table results

Let us know what environment you are running this on

OS: Linux 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64
Shell:  /usr/sbin/nologin
PHP binary: /usr/local/lsws/lsphp81/bin/php
PHP version:    8.1.24
php.ini used:   /usr/local/lsws/lsphp81/etc/php/8.1/litespeed/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.6.12-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:  
WP-CLI root dir:    phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:  phar://wp-cli.phar/vendor
WP_CLI phar path:   /var/www/xxxxx/html
WP-CLI packages dir:    /nonexistent/.wp-cli/packages/
WP-CLI cache dir:   /nonexistent/.wp-cli/cache
WP-CLI global config:   
WP-CLI project config:  
WP-CLI version: 2.7.1

LSPHP modules installed: lsphp81 lsphp81-common lsphp81-curl lsphp81-igbinary lsphp81-imagick lsphp81-imap lsphp81-intl lsphp81-msgpack lsphp81-mysql lsphp81-opcache lsphp81-redis

[danielbachhuber]

Thanks for the report, @redbullpeter

This issue is already tracked with https://github.com/wp-cli/profile-command/issues/126

As far as I know, it hasn't been fixed in PHP yet, and we haven't embarked upon the refactor for it.

Is there additional context you can share? Would it be satisfactory to simply update the error message to mention PHP 7 and PHP 8?

[swissspidy]

The mentioned PHP bug was closed as wontfix as it's intended behavior.