Looking for help getting Xdebug working

[RhoVisions]

I wasn't sure if this better belonged here or the editors forum, so if this should be elsewhere, I hope an admin can move it for me.

 

I finally decided to start using Xdebug, as I read up about it's great merits for debugging over just dumping out variables. Unfortunately, of course my forie into something new failed from the get go. I'm developing on an Ubuntu 14 VirtualBox, and looking at phpinfo, xdebug was already installed and setup, though none of the configs were in php.ini. As I develop on Atom, I found a StackOverflow answer on setting up xdebug and atom. Unfortunately, when I started using it, though after some problem solving I can get the debug pane to come up and says it's listening to my VM, adding a breakpoint doesn't actually pause my app; everything runs as if I did nothing.

 

Unfortunately, I can't tell if I setup xdebug incorrect, if it's not working correctly, something's wrong with my Atom setup, or I'm just not understanding xdebug in general. I'm hoping someone more experienced can help me get on my feet for what looks like an awesome tool

[kicken]

Did you configure the xdebug values in your INI file according to the stack overflow post? Does phpinfo() confirm they values are configured properly?

 

You'll likely also need to set the xdebug.idekey value. According to this post the value should be set to xdebug.atom.

 

Also make sure you don't have any firewall's blocking the xdebug.remote_port port.

[requinix]

In Ubuntu the various PHP extensions have their own .ini files. If you want/need to make changes, find the Xdebug settings in PHP's conf.d directory.

[RhoVisions]

Thanks for the initial replies.

 

Did you configure the xdebug values in your INI file according to the stack overflow post? Does phpinfo() confirm they values are configured properly?

You'll likely also need to set the xdebug.idekey value. According to this post the value should be set to xdebug.atom.

Also make sure you don't have any firewall's blocking the xdebug.remote_port port.

 

Yes, I setup the xdebug values in php.ini, trying both the values in the Atom package docs and the SO answer. phpinfo() validates the values.

 

According to the package doc, the idekey is xdebug-atom (I saw xdebug.atom in some posts as well), so I tried both values; neither worked.

 

I'm not sure how to check the firewall. I checked netstat -a -b and I didn't see anything using the port, but should I be checking the Windows host port 9000 or the Ubuntu port?

 

In Ubuntu the various PHP extensions have their own .ini files. If you want/need to make changes, find the Xdebug settings in PHP's conf.d directory.

 

The xdebug ini only had the link to the xdebug so file; no settings in there. Making the changes in php.ini did reflect in phpinfo() though.

[requinix]

What are your current Xdebug settings?

 

The xdebug ini only had the link to the xdebug so file; no settings in there. Making the changes in php.ini did reflect in phpinfo() though.

Making the changes in the xdebug.ini would have worked too. In fact that's what you're supposed to do.

[RhoVisions]

What are your current Xdebug settings?

 

Making the changes in the xdebug.ini would have worked too. In fact that's what you're supposed to do.

 

I'll move the changes over; thanks for letting me know. As for my settings, here's what I added, everything else left default (I can screenshot the full values if it's beneficial?)

xdebug.remote_autostart = 1
xdebug.remote_log = /tmp/xdebug.log
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
#xdebug.remote_host=192.168.56.1
xdebug.remote_port = 9000
xdebug.idekey = xdebug-atom

Having looked around online and through the xdebug docs, I tried both a remote host ip as well as remote_connect_back.

[kicken]

I'm not sure how to check the firewall. I checked netstat -a -b and I didn't see anything using the port, but should I be checking the Windows host port 9000 or the Ubuntu port?

You'd check the windows host. The debugger is the one that listens for connections so that's where you'd find the socket. Something like:

  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING

[RhoVisions]

You'd check the windows host. The debugger is the one that listens for connections so that's where you'd find the socket. Something like:

  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING

 

That's what I figured. Nothing listening on 9000.

[gizmola]

What type of networking are you using with virtualbox?

[RhoVisions]

What type of networking are you using with virtualbox?

 

I have 2 adapters setup, a NAT and a host-only.

[gizmola]

I saw that you were missing an IP address in the callback. XDebug will callback to the editor on the IP and port in the xdebug config.

 

With that said, it seems that Atom does not have a listener open to receive the callback, but both things need to be in place. You have this line commented out:

 

#xdebug.remote_host=192.168.56.1

I would make sure that is the Host IP on the NAT network. It could be the host only network adapter as well, but you would also have to go in and set up port forwarding for 9000 in the adapter.

[requinix]

I saw that you were missing an IP address in the callback. XDebug will callback to the editor on the IP and port in the xdebug config.

Unless remote_connect_back is set, when Xdebug will ignore the remote_host and connect back to whatever remote IP is connecting.

[RhoVisions]

I tried it with both remote_host and remote_connect_back, as different tutorials suggested each. And I confirmed by IP by checking phpinfo(). As the NAT is set to 192.168.56.102, i guess it kind of makes sense that the connecting IP is 56.1?

[kicken]

By default I think, the VM's NAT interface IP is usually 10.0.2.15, and the host would be 10.0.2.2 (though the host's interface IP should work also).

 

192.168.56.x is typically the host-only network. There's really no reason to have both interfaces in your VM unless you need them for some other reason.

 

I think your first thing to do should be to figure out how to get atom to listen on the host machine for connections. Until that's working the xdebug configuration doesn't really matter. When you're checking the netstat output on the host machine look for a listening socket on port 9000 (or whatever port atom is configured for) on any interface, not just 0.0.0.0. PHPStorm for example by default only listens on 127.0.0.1 if I remember correctly, which would not work if you were using a host-only setup.

 

When you've got atom listening properly, configure xdebug.remote_host with the host's IP and disable xdebug.remote_connect_back.

[RhoVisions]

By default I think, the VM's NAT interface IP is usually 10.0.2.15, and the host would be 10.0.2.2 (though the host's interface IP should work also).

 

192.168.56.x is typically the host-only network. There's really no reason to have both interfaces in your VM unless you need them for some other reason.

 

I think your first thing to do should be to figure out how to get atom to listen on the host machine for connections. Until that's working the xdebug configuration doesn't really matter. When you're checking the netstat output on the host machine look for a listening socket on port 9000 (or whatever port atom is configured for) on any interface, not just 0.0.0.0. PHPStorm for example by default only listens on 127.0.0.1 if I remember correctly, which would not work if you were using a host-only setup.

 

When you've got atom listening properly, configure xdebug.remote_host with the host's IP and disable xdebug.remote_connect_back.

 

Thanks for the detailed feedback. I trust you're right; I must have mixed up which is the NAT and the host-only. As for why I have both, when I first created the VM, it had the NAT only, and I couldn't get it to connect to the internet through the host. Through googling, I found that the only way to both server locally and have it connect to internet through the host was with a NAT for serving and a host-only for the internet. If that's wrong, I'd love advice on how to get it working, as I wasn't able to find another way. Looking at the Vagrant boxes at work, they have the same setup.

 

Following your instructions, seems like no matter what IP I change it to, atom is only listening on 127.0.0.1, which I think means it's the Atom package itself. I hope so, because after reading so many instructions and looking for advice, the fact that it fails because of the app is kind of nice to know. It makes me debate spending the money for PHPStorm, though there are Atom features I really like...

[gizmola]

Yes true. NAT networking provides a high level of isolation. I don't see much reason to use NAT with Host only.

 

What you actually want is probably a bridged network. This will make the VM look like another machine on your local network, and then your configuration becomes a lot more basic. It's just getting the configuration of each machine to use the IP and port combination for each. Bridged will also provide you internet access from your vm.

[requinix]

Another solution: SSH tunnel. Connect over SSH, even if you're just leaving the terminal open, and have it set up a tunnel from the "remote" port 9000 to the "local" port 9000. Then set Xdebug to connect to the host 127.0.0.1. That way Xdebug will try to connect to 127.0.0.1:9000, but with the tunnel in place it will "forward" to your local port 9000 - which is what Atom is listening on.

 

The SSH session is an extra step when you want to debug, but it's barely any more work.