Mam bramkę z zainstalowaną xdebug, uruchomioną na OSX, ale staram się uzyskać wtyczkę Atom Xdebug (php-debug), aby połączyć się z nim.

Wkleiłem dane phpinfo(); do witryny walidacyjnej Xdebug i powiedział, że wszystko było dobre. I możesz zobaczyć wszystkie ustawienia Xdebug.

Mam mapowany port 9000 w pliku Vagrant.

config.vm.network :forwarded_port, guest: 9000, host: 9000

Pudełko Vagrant ma tylko sieć hosta, która eksponuje 192.168.10.100 jako IP serwera.

I próbowałem wszelkiego rodzaju opcji Xdebug, te na stronie wtyczki ATOM sugerują ..

xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true

Ale to jest lekko mylące jak remote_connect_back=1 oznacza, że xdebug zignoruje ustawienie remote_host - więc nie jestem pewien, dlaczego oboje tam są - ani pracy.

Ponownie uruchomiłem Apache / PHP po za każdym razem, gdy zmieniam opcje i sprawdzić, czy są ładowane phpinfo();

Jeśli sprawdzę, kto słucha portu 9000

COMMAND     PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Atom\x20H 10656 Matt   28u  IPv6 0x321cb0a96ba5b593      0t0  TCP *:cslistener (LISTEN)
VBoxHeadl 10889 Matt   19u  IPv4 0x321cb0a981a71433      0t0  TCP *:cslistener (LISTEN)

Możesz zobaczyć zarówno włóczęgę (wirtualne pudełko), jak i atom. Chociaż atom jest IPv6, który jest dziwny ....

Ale umożliwiając debugger w atomie, ustawiając punkt przerwania i uderzając w stronę, nic się nie dzieje - atom nigdy się nie łączy.

Jakieś pomysły? Czy ktoś dostał to do pracy?

0
Matt Bryson 15 luty 2017, 19:30

2 odpowiedzi

Najlepsza odpowiedź

Ale to jest lekko mylące jak remote_connect_back=1 oznacza, że xdebug zignoruje ustawienie remote_host

Jesteś poprawny - ta opcja nie jest tam potrzebna - lepiej być ustawiona na 0

xdebug.remote_host = 127.0.0.1.

To jest nie tak (chyba że będziesz robić debugowanie przez tunel SSH). To musi być IP, w którym działa klient debugowania (atom w twoim przypadku). To Xdebug, który łączy się z klientem , a nie na inny sposób: https://xdebug.org / Dokumenty / zdalne

Oznacza to również, że IP musi być widoczny z tej maszyny włóczęgowej. Prawdopodobnie najłatwiejszy sposób na zdobycie - spójrz na to, co ma $_SERVER['REMOTE_ADDR'].

Mam mapowany port 9000 w pliku Vagrant.

config.vm.network :forwarded_port, guest: 9000, host: 9000

Nie musisz ujawniać 9000 portów w Vagrant - nikt z nim nie będzie się z nim połączyć (jak z portem 80 dla serwera WWW) - to Xdebug z VM / Guest OS będzie łączy się na zewnątrz "Real" / Host Host OS .

Jeśli coś - powinieneś zezwolić na połączenia wychodzące na tym porcie zamiast przychodzącego.

Jeśli sprawdzę, kto słucha portu 9000

Ten oznacza, że atom nie jest w stanie odbierać przychodzącego połączenia XDebug nad TCPV4 .. Który Xdebug spróbuje użyć domyślnie (chyba że określisz adres IPv6 w xdebug.remote_host).


Jeśli cokolwiek - zbieraj dziennik xdebug (xdebug.remote_log) i zobacz, gdzie próbuje połączyć się itp

4
LazyOne 17 luty 2017, 16:00

@Lazyone już odpowiedział na to pytanie, ale problem, który miałem, był spowodowany antywirusem (McAfee), który blokował ruch przychodzący. Może to pomoże komuś w przyszłości.

0
Filip Sobol 23 luty 2017, 20:10