vscode-php-debug icon indicating copy to clipboard operation
vscode-php-debug copied to clipboard

Launching local php executable for remote projects

Open t-schroeder opened this issue 4 years ago • 11 comments

Details

PHP version: 7.3.31 Xdebug version: 2.9.8 VS Code extension version: 1.21.0

Your launch.json:

Click me
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}"
        }
    ]
}

Xdebug php.ini config:

Click me
zend_extension=xdebug.so
xdebug.collect_params = 1
xdebug.idekey = vscode-xdebug
xdebug.max_nesting_level = 1000
xdebug.profiler_append = 1
xdebug.profiler_enable_trigger = 1
xdebug.profiler_enable_trigger_value = "bla"
xdebug.profiler_output_dir = /home/php-profiling
xdebug.remote_autostart = true
xdebug.remote_enable = true
xdebug.trace_enable_trigger = true
xdebug.trace_enable_trigger_value = "blub"
xdebug.trace_format = 1
xdebug.trace_options = 1
xdebug.trace_output_dir = /var/www/trace
xdebug.var_display_max_depth = 7

Xdebug logfile (from setting xdebug.log in php.ini): empty VS Code extension logfile (from setting "log": true in launch.json):

Click me
<- launchResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true
}
<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }
<- outputEvent
OutputEvent {
  seq: 0,
  type: 'event',
  event: 'output',
  body: {
    category: 'console',
    output: 'Error: spawn C:\\php-7.3.9-nts-Win32-VC15-x64\\php.exe ENOENT\n' +
      '    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)\n' +
      '    at onErrorNT (internal/child_process.js:465:16)\n' +
      '    at processTicksAndRejections (internal/process/task_queues.js:80:21) {\n' +
      '  errno: -2,\n' +
      "  code: 'ENOENT',\n" +
      "  syscall: 'spawn C:\\\\php-7.3.9-nts-Win32-VC15-x64\\\\php.exe',\n" +
      "  path: 'C:\\\\php-7.3.9-nts-Win32-VC15-x64\\\\php.exe',\n" +
      "  spawnargs: [ '/home/st-admin/moodle-webservice-client/get_contents.php' ]\n" +
      '}\n'
  }
}
Error: spawn C:\php-7.3.9-nts-Win32-VC15-x64\php.exe ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
    at onErrorNT (internal/child_process.js:465:16)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn C:\\php-7.3.9-nts-Win32-VC15-x64\\php.exe',
  path: 'C:\\php-7.3.9-nts-Win32-VC15-x64\\php.exe',
  spawnargs: [ '/home/st-admin/moodle-webservice-client/get_contents.php' ]
}
-> setFunctionBreakpointsRequest
{
  command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 3
}
<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 3,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] }
}
-> setExceptionBreakpointsRequest
{
  command: 'setExceptionBreakpoints',
  arguments: { filters: [] },
  type: 'request',
  seq: 4
}
<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 4,
  command: 'setExceptionBreakpoints',
  success: true,
  body: { breakpoints: [] }
}
-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 5 }
<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 5,
  command: 'configurationDone',
  success: true
}
-> threadsRequest
{ command: 'threads', type: 'request', seq: 6 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 6,
  command: 'threads',
  success: true,
  body: { threads: [] }
}

Code snippet to reproduce:

<?php
echo "hello";

Description

I'm running vscode on a Windows 10 machine connected via "Remote - SSH" extension to a CentOS 7 machine. Since updating "PHP Debug" extension to version 1.20 it always launches the local php binary to execute remote php scripts. That gives me this error:

Error: spawn C:\php-7.3.9-nts-Win32-VC15-x64\php.exe ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
    at onErrorNT (internal/child_process.js:465:16)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn C:\\php-7.3.9-nts-Win32-VC15-x64\\php.exe',
  path: 'C:\\php-7.3.9-nts-Win32-VC15-x64\\php.exe',
  spawnargs: [ '/home/st-admin/moodle-webservice-client/get_contents.php' ]
}

With version 1.19 the extension uses the remote php binary when I have a remote folder opened and tell it to execute a php script in there.

Workarounds

Either:

  • go back to version 1.19 or
  • put "php.executablePath": "/usr/bin/php" in the settings.json for the Remote.

t-schroeder avatar Oct 21 '21 18:10 t-schroeder

Hi! You are right there were some changes in 1.20.

The plugin tries to figure out where the PHP executable is.

  1. It checks in the launch.json if runtimeExecutable is defined
  2. if not it checks setting php.executablePath
  3. if not it checks setting php.validate.executablePath
  4. if not it checks if php executable is in path
  5. if not, if informs the user it can't find it and offers to open settings

It could be, that if you have it set in you local user properties, that it gets transferred over to remote, but then you'd already have problems with code validation... so overriding it on remote is the proper way.

Do you have a suggestion on how I could do it differently?

zobo avatar Oct 21 '21 20:10 zobo

I believe I'm getting errors related to this as well. I cannot use PHP Debug and PHP Intellisense at the same time - they have a conflict with php.executablepath. It was driving me insane with my Laragon-based site stalling out repeatedly when I used xdebug.

Whichever one is enabled first will work. xDebug is my priority, but I NEED Intellisense too!

I'm happy to help debug anything if necessary.

https://user-images.githubusercontent.com/88559987/138384496-0deb861b-2495-4914-a225-6d4762caec75.mp4

nickchomey avatar Oct 22 '21 02:10 nickchomey

Hi @nickchomey.

That is correct, they do have a conflict in this setting. I choose this setting but then later re-published PHP IntelliSense and just then realized that this causes a conflict.

However, this is just a warning and they should still both work (at least this is my experience here).

Do you need to use different PHP versions? Can you tell me how it does not work? Is IntelliSense reporting any errors?

Also, I'm not sure how both "PHP Intelephense" and "PHP IntelliSense" work together, since they both provide a language server...

Edit: Do you need different PHP versions for IntelliSense (min PHP 7.4) and Debug?

zobo avatar Oct 22 '21 03:10 zobo

Thanks for the quick reply!

As I mentioned, I was having considerable problems with xdebug for the past few days since installing Laragon. Pages would randomly (and pretty quickly) stop loading altogether once I enabled xdebug and step debugging. They'd just sit there with the page load spinner going indefinitely. It was very difficult to get it to work again - I couldn't find any reliable solution (restart Laragon, VS Code, xdebug, etc...).

But as soon as I disabled Intellisense, the problems didn't recur in about an hour of working/testing (whereas it was every 5 minutes before).

Intelephense does not seem to be contributing to the problem. It allows for finding references to and definitions of different functions. Intellisense, if I'm not mistaken, allows for autocomplete of code (among other things). Completely different functionalities, but I need it even more than Intellisense should there be a conflict there.

I do not need different PHP versions - 7.4 is fine for my needs and is the only one installed in my local Laragon server.

I just uninstalled 1.21 and installed 1.19 manually, as per the suggestion in the OP, and the conflict error message that I showed in the video goes away. I need to sleep now, but will test it tomorrow.

Please let me know if there is anything I can do to help debug this further.

nickchomey avatar Oct 22 '21 04:10 nickchomey

I just started my day and can work on this after work. I do not have experience with Laragon...

After installing 1.19 did the problems also stop?

I think Intelephense also provides all of that, but you need to pay for it. PHP IntellIsense also provides definition lookups and jump-to. I'd suggest trying to disable one of them.

It's really strange that this things would conflict with each other... Can you check under OUTPUT / PHP Language Server if there are any errors?

image

When your page stop/stall is the debugger active? If you add "log": true to your launch configuration, does it show anything?

You are probably using Listen for Xdebug? And there that setting should not have any effect...

zobo avatar Oct 22 '21 04:10 zobo

It could be, that if you have it set in you local user properties, that it gets transferred over to remote, but then you'd already have problems with code validation... so overriding it on remote is the proper way.

You're right. I had php.validate.executablePath set in my local settings.json. I don't remember where this setting is from so just commented it out which also fixes the problem.

Do you have a suggestion on how I could do it differently?

Knowing the order in which the extension checks the different settings is enough for me. You don't need to change anything from my perspective. I would close this issue again but I'll leave it open for @nickchomey.

t-schroeder avatar Oct 22 '21 09:10 t-schroeder

Thanks for your feedback. I think I still need to change it as - it seems - two extensions can't offer the same setting. They can use the same setting, but cant register it in the settings panel. So I will probably add php-debug.executablePath setting and use it as the first choice...

zobo avatar Oct 22 '21 11:10 zobo

Well, I'm embarrassed. I'm not sure why I thought Intellisense and Intelephense did different things. After some quick testing, Phense is both considerably faster at loading definitions and does it with lower CPU load, so I've uninstalled Sense. I'll test PHP Debug/xdebug and open a separate issue there if I continue to have problems. Sorry for the trouble and thanks for the responses!

nickchomey avatar Oct 22 '21 22:10 nickchomey

For others' reference, my issues persisted with Sense and Phence disabled, and with both PHP Debug 1.21 and 1.19. I can't find any reliable solution other than reverting to xDebug 2.9.8.

nickchomey avatar Oct 23 '21 16:10 nickchomey

I'd suspect it has more to do with Laragon than either PHP IntelliSense or *Phence. I'll see if I can manage to test it, but since vanilla PHP works without issues, I'm not sure how deep I can afford to dig there...

zobo avatar Oct 24 '21 12:10 zobo

Could be laragon, but there are people in Laragon forums who who use v3 successfully and I'll followed their tutorials precisely. Probably some combo of laragon, xdebug and my windows config - I tried all sorts of things with firewall, hosts, disabled internet and more, to no avail. Don't look much into this for my sake, but I'd be appreciative if someone ever gets to the bottom of it!

nickchomey avatar Oct 24 '21 15:10 nickchomey

I'll close this as the resolving of executablePath changed in #685.

zobo avatar Apr 03 '24 14:04 zobo