Debugging for console seems not to work properly


#1

At the moment, i am experiencing a very strange behaviour.
Debugging console commands is not possible at all, the breakpoint does not hit.

What i tried to do:

  1. Setting a breakpoint in DataImportBusinessFactory on line 328 ($dataSetStepBroker->addStep …) in my IntelliJ/PhpStorm IDE (under MacOS)

  2. Executing

vendor/bin/console data:import:product-concrete

from command line in vagrant vm.

Expecting:

  • Breakpoint stops at line 328
  • variable $dataSetStepBroker is initialized (done one line before according to source code with dataSetStepBroker = …)

Actual:

  • Breakpoint stops at line 328
  • variable $dataSetStepBroker is not set until now
  • if i step over to line 329, the variable is now set (even tough there is not such an command to do this)
  • further steps more the debugger stops on an empty line

So obviously there is a bug synchronizing sourcecode between vm and local dev. The IntelliJ is always one step ahead the real debugging line.

I found out, that this affects all classes loaded by the autoloader in vendor/bin/console php file. The vendor/bin/console itself debugs proper. So maybe autloading/symlinks causes the problem?

Any ideas?

Best regards


#2

Hi Jim!
You can try to add script to debug in PhpStorm:
go to Run -> Edit Configuration. Press plus and add new PHP Script.


And configure like this.
Than run this script with debug.

Best Regards,
Aleksey Kotsuba.


#3

I haven’t experienced this behaviour before, but following the academy topic on this, never failed me.

https://academy.spryker.com/getting_started/debugging/debugging_setup.html (the section of “Debugging Console Commands”)


#4

Unfortunately same behaviour for local debugging setting :confused:


#5

Do you also work with vagrant/intellij/MacOS? That would leaving me hopeful … i’ll try to start completely on a fresh installation


#6

Yes, you are running the command from within the devvm, right?


#7

Yes i do. But i also tried outside.


#8

Ok i reinstalled the whole thing. Same behaviour for console commands.

In vm executing

XDEBUG_CONFIG=“remote_host=10.10.0.1” PHP_IDE_CONFIG=“serverName=zed” vendor/bin/console data:import:product-concrete

Breakpoint set on line 328.

Result: Breakpoint stops but is factual in line 327.

Debugging via frontend works fine.

What else can i do?


#9

I found out that only files from src/ folder are affected. All vendor code works and hits the correct line. just the existing code in src/ does not work properly. But only for command line executed PHP. My guess is, that the PHP_IDE_CONFIG=“serverName=zed” has no effect to the IDE … it does not matter if I write something like PHP_IDE_CONFIG=“serverName=zed” or PHP_IDE_CONFIG=“serverName=dfjkofkdfpmpmw” the result is still the same.

Edit:
Okay, it just seems it works correct. If i set a breakpoint on the line which is shown in the stack, it will not stop here … this is really weird and frustrating

Edit 2:
Ok, only console.php works properly … all other files (included) don’t work properly.

Edit 3:
I duplicated the line “require_once SPRYKER_COMPOSER_INSTALL;” in console.php by mistake … but now the breakpoints seems to work properly.

I pressed cmd+z to undo these changes to track that this really issues the problem. But … the debugger still works correct.
Can somebody explain me this behavior? :thinking:

Edit 4:
The correct debugging behavior is gone again now, the debugger stops at the wrong line again … i can’t reproduce a working state. Duplicating the code line from edit above does not trigger the correct debugging behavior … :confused:


#10

Hello
I am again at this problem and trying to find a solution. What i found out now is:

In the vagrant vm there are two locations that are interesting:

/vagrant/project

/data/shop/development/current

In booth locations it seems that here is the mounted source code from the host machine. I tested it by creating a file in host code location and it appears on vm in both mentioned locations.

The difference:

If i run vendor/bin/console from command line in the location /data/shop/development/current (as described in the debugging description from spryker), the weird debugging behaviour comes up

If i run the sam vendor/bin/console from /vagrant/project all works perfect. But here the command runs painfully slow. Its 20-30 times slower than in the not working directory.

For me, this smells really like a nfs/filesync problem inside vagrant or with the host.

Can somebody explain me, why there are two locations for sourcecode mapped from host to vm? How is it working in detail?

Thanks


#11

Please try this command before running debug:
sudo phpdismod opcache


#12

Hi JimPanse,

Thanks for your report. That gives us at least a clue. Could you please check for me if both files have the same contents? You can use for example the command:

md5sum /data/shop/development/current/(path) /vagrant/project/(path)

As a (path) provide the path to the PHP file, which gives inconsistencies in xdebug. If you see that the hash of both files differs, it means that you are getting some “in-flight” translation. In that case, please provide output of:

diff /data/shop/development/current/(path) /vagrant/project/(path)

You have asked about file sharing setup details. Let me qive you a quick summary of it. For details of implementation, take a look at Vagrantfile-quick file in devvm github repository.

  • /vagrant in guest is mapped to directory which contains Vagrantfile on your host. It is default behavior of Vagrant. It uses virtualbox shared folders, a method which proved to be too slow for PHP. As you noticed, execution times were unacceptable when using files from this location, so it’s not used by Spryker Dev VM
  • /data/shop/development/current is mapped to your project directory on host. It is our addition (see Vagrantfile-quick) and a result of many tries and benchmarks to minimise development friction coming from performance issues.

NFS proved to be stable for Linux and Mac OS and seems that it did a good job, but apparently some setups are broken, so let’s try to find cause for this.

Could you please also let me know about:

  • exact versions of Vagrant, VirtualBox, your operating system, dev vm
  • did you ever customise your NFS sharing settings?
  • are you using other applications which could alter your host NFS settings? I am aware that some apps could change your settings, minikube, docker-machine belong to them
  • does enabling/disabling of opcache has any impact?

Best regards,
Marek Obuchowicz
KoreKontrol - Spryker hosting company


#13

Many thanks for the help and suggestions. At the moment (after about 3-4 reinstallations of the vagrant vm), debugging is working again (maybe until next vagrant destroy & up). At the moment i am glad for this circumstance. If the behaviour occurs again, i’ll try the provided suggestions but i don’t want to force this situation at the moment.

Many thanks!


#14

Ok, the error is acute again. Deactivating the opcache with

sudo phpdismod opcache

seems to work immediately. The error is gone. I’ll be carefully first with this statement as i fear the error comes back again (like several times before).

Could you please check for me if both files have the same contents?

Yes of course! It seems to be the same content in both files.

0c8c611baabb9c4ab922e86d674686ca  /data/shop/development/current/src/Pyz/Zed/CustomerImport/Dependency/Facade/CustomerImportToProcessFacadeBridge.php
0c8c611baabb9c4ab922e86d674686ca  /vagrant/project/src/Pyz/Zed/CustomerImport/Dependency/Facade/CustomerImportToProcessFacadeBridge.php

Here are the requested system details

Vagrant Version 2.1.5
Virtualbox Version 5.2.22r126460
MacOS Mojave 10.14.1
Spryker v2.1.0 spryker-devvm.box

  • did you ever customise your NFS sharing settings?

no

  • are you using other applications which could alter your host NFS settings? I am aware that some apps could change your settings, minikube, docker-machine belong to them

I have installed docker for mac since i wanted to try the spryker docker stack. That hasn’t worked as i expected so i switched back to vagrant. Docker for mac is not active, when i run the vagrant box.

  • does enabling/disabling of opcache has any impact?

Yes, the errors seems gone now (carefully said)


#15

Okay, it’s definitely the opcache … i can switch between erroneous and working behavior …

That saves my day so far.

Thank you very much!


#16

JimPanse, happy to have this problem solved.
Could you check one more thing for me? I got a suggestion that disabling opcache completely is not required and it’s enough to set:

opcache.enable_cli=0

in opcache configuration file (/etc/php/…).

If you had a few minutes, could you please check if it’s working for you with opcache enabled and the setting above? We’d like to find out optimal solution that has lowest performance impact. If it’s possible to keep opcache running for web requests, disable it for CLI and have working XDebug - it’s my preferred way to put in the dev vm.

Thanks a lot!
Marek


#17

Hello Marek,

i did the following now.

  • Reproduced the erroneous behavior by enabling opcache again (sudo phpenmod opcache)

  • Start debugging session and checked that the error is present again (CustomerImportToProcessFacadeBridge.php)

  • edit file /etc/php/7.2/mods-available/opcache.ini and set opcache.enable_cli=0

  • saved file and restarted php with sudo -i bash -c "systemctl restart php7.2-fpm.service"

  • checked configuration with command line php -i

    Output

    opcache.enable => On => On
    opcache.enable_cli => Off => Off

  • Checked erroneous behavior again

    Result: Error is gone

Thanks a lot!


#18

Thanks for this feedback, appreciated!