Home » Php » php – xdebug profiling from command line doesn't work

php – xdebug profiling from command line doesn't work

Posted by: admin July 12, 2020 Leave a comment

Questions:

When I try to run xdebug profiling (from the command line), the script immediately dies. I don’t receive any feedback. (If I run the script with xdebug profiling turned off, then the script performs exactly like I would expect.) I am running php 5.4.13 in Centos 6.

I have tried two different ways to enable profiling: editing php.ini, and using the -d flag when I execute the script.

The relevant part of my php.ini looks like this:

[xdebug]
zend_extension="/usr/lib64/php/modules/xdebug.so"
xdebug.remote_enable = 1
xdebug.default_enable = 0
xdebug.profiler_output_dir = "/tmp/profiling"
# xdebug.profiler_enable = 1  # I uncomment this line to try to profile my script

I call the script using one of these two commands (and make sure the ini file line is commented out (or not) as appropriate).

$> /usr/bin/php scripts/daemon/PostProcess.php -c 4

or

$> /usr/bin/php -d xdebug.profiler_enable=1 scripts/daemon/PostProcess.php -c 4

I am confident that the setting is being interpreted correctly.

$> php -d xdebug.profiler_enable=1 --info | grep profile | less

xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => On => On
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_output_dir => /tmp/profiling => /tmp/profiling
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p

xdebug works correctly for debugging. The following command works just fine:

$> /usr/bin/php -d xdebug.remote_autostart=On -d xdebug.remote_host=A.B.C.D scripts/daemon/PostProcess.php -c 4

Any ideas?

How to&Answers:

Try running the script with -ddisplay_errors=1 to force displaying PHP errors. Example:

/usr/bin/php -ddisplay_errors=1 -d xdebug.profiler_enable=1 scripts/daemon/PostProcess.php -c 4

Generally, when I have the issue you described, I have an error in my code and display_errors is off by default to prevent potentially leaking sensitive details in an error message. Thus, the message with the error is hidden. See if this gives you information to correct the issue.