search

Varying-Vagrant-Vagrants / VVV

An open source Vagrant configuration for developing with WordPress
https://varyingvagrantvagrants.org
MIT License
4.54k stars 848 forks source link

Xdebug throwing warnings/errors #2321

Closed roykho closed 3 years ago

roykho commented 3 years ago

Expected Behavior

I am expecting there to be no output from Xdebug in the PHP error logs.

Current Behavior

[18-Dec-2020 14:00:30 UTC] Xdebug: [Step Debug] Could not connect to debugging client. Tried: 192.168.50.1:9000 (from REMOTE_ADDR HTTP header), 192.168.50.1:9000 (fallback through xdebug.client_host/xdebug.client_port) :-(

[18-Dec-2020 14:00:31 UTC] Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9000 (from REMOTE_ADDR HTTP header), 192.168.50.1:9000 (fallback through xdebug.client_host/xdebug.client_port) :-(

When you turn on Xdebug by using xdebug_on and just navigate around a site that is provisioned, you will see these warnings/errors in your PHP error logs and it will keep generating them as your site is loading different pages.

Steps to Reproduce (for bugs)

  1. Checkout latest from develop branch.
  2. vagrant up --provision
  3. After it provisions, vagrant ssh
  4. Then run xdebug_on
  5. Go check your PHP error log. For me that was php7.3_errors.log. At this time you might already see some warnings/errors but if not, go to one of your provisioned sites and load it up. You should then see them.

Note: I am also seeing this one notice at the very beginning of turning Xdebug on [18-Dec-2020 13:57:59 UTC] Xdebug: [Config] The setting 'xdebug.default_enable' has been renamed, see the upgrading guide at https://xdebug.org/docs/upgrade_guide#changed-xdebug.default_enable (See: https://xdebug.org/docs/errors#CFG-C-CHANGED)

Also this does not seem to hinder the actual functionality of debugging, however it continuously pollutes the PHP error logs making it hard to see legitimate PHP errors in the application.

tomjn commented 3 years ago

@roykho can you give https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2322 a test and see if that helps? Note it changes the port to 9003 which is the default port XDebug 3 uses

roykho commented 3 years ago

Yeah I am still seeing the same thing.

[18-Dec-2020 14:42:08 UTC] Xdebug: [Step Debug] Could not connect to debugging client. Tried: 192.168.50.1:9003 (from REMOTE_ADDR HTTP header), 192.168.50.1:9003 (fallback through xdebug.client_host/xdebug.client_port) :-(

[18-Dec-2020 14:42:08 UTC] Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9003 (from REMOTE_ADDR HTTP header), 192.168.50.1:9003 (fallback through xdebug.client_host/xdebug.client_port) :-(

tomjn commented 3 years ago

so it might be that the auto-discovery couldn't connect so it fell back too client_host/client_port and it's just being super noisy about reporting that, you mentioned it still works as expected despite this?

tomjn commented 3 years ago

A quick update, I reproduced the issue, and fixed the deprecation warnings, but it required setting the client host to _gateway which seems odd to me. I'd like it if others can test the PR and confirm it works for them. The PR also adds VSCode configs that should make testing super easy

rodrigoprimo commented 3 years ago

Just to report that after the PR mentioned here, I'm getting a slightly different error in the logs (I was getting the same error that @roykho reported before):

Xdebug: [Step Debug] Could not connect to debugging client. Tried: _gateway:9003 (through xdebug.client_host/xdebug.client_port) :-(

This is on a brand new VVV instance using the develop branch.

tomjn commented 3 years ago

@rodrigoprimo did you have an active xdebug session with a step debugger at the time? If you turn on xdebug but do not have a step debugger running, e.g if you're only interested in the development aids, then yes the PHP error log will have these messages, and it's intended behaviour according to the xdebug maintainer

tomjn commented 3 years ago

I'm going to close this as it's an issue with a 3rd party not VVV. Xdebug decided this was desirable behaviour, short of forking Xdebug there's very little that can be done from the VVV side ( we can kill all log output from xdebug for which there's a PHP, but then there will literally be nothing in the xdebug log, even a catastrophic failure won't show up )

roykho commented 3 years ago

That's a shame that was their response (it didn't work like that in Xdebug previous version). If anything it should be controllable via config. So not ideal but we just have to turn Xdebug off when not actually stepping through. Perhaps add a convenience button on VVV dashboard to quickly toggle it would be nice.

Thanks for trying to help @tomjn

tomjn commented 3 years ago

I've raised https://bugs.xdebug.org/view.php?id=1935 as well to ask for a way to turn it off, but right now it's just me and only me. It needs support or it just looks like I want my personal preference made law.

0001935: Failure to connect logs to the PHP error log - MantisBT
roykho commented 3 years ago

I also voiced my concern over there.

adrianahdez commented 3 years ago

I solved it pointing my error_log to a valid location by adding this line to my php.ini (in /etc/php/7.4/cli/php.ini):

error_log = /var/www/log/php_error.log

Change that location to any valid directory you want.

tomjn commented 3 years ago

@adrianahdez I'm not sure we're referring to the same problem, this issue is for xdebug warning about connection loopbacks in the error log. VVV should be routing errors to a file in a shared folder log/php/php7.4-fpm.log