Can't get PHPStorm and Xdebug debugger to connect up

Hi folks,
I'm running PHPStorm v4.0.3 on a Windows 7 Ultimate x64 platform. It runs on an Oracle VirtualBox VM under a host version of Windows 7 Pro running on fairly new (~1.5 yr.old) Dell box. Virtual networking is in use, but my problems are all with the localhost server running on the same VM as PHP Storm. Nothing fancy there, I don't think. At least I'm not trying to run PHPStorm on the host and webserver in the guest or anything; both are running inside the guest VM. This may be relevant.

I'm using (and very happy with) the WAMP server package called Uniform Server located in c:\uniserver. It has PHP 5.4.0 running in its usr\local\php folder

I'm having problems getting the debugger to connect up. I've tried the usual settings and such, and I know that Xdebug 2.2.1 (latest) is installed properly because I can run a PHP test script locally under the debugger. Breakpoint set, hit the Debug/Run button, and voila, it's stopped at the breakpoint.

When I try to set things up for remote use on the local server, PHPStorm hangs waiting for a connect with an IDE key that's some 5-digit number. This in spite of my PHP.INI setting for xdebug.idekey=MikeM.
I've been at this for a few days, but it only ran once on a fluke, and I can't get it to repeat. This is also relevant, I think.

Making a longer story short, I finally found out how to do the logs and this is what I found.
Every failed connection attempt looks like this (my underlining on the addresses):


     Log opened at 2012-08-26 11:17:40
     I: Checking remote connect back address.
     I: Remote address found, connecting to ::1:9000.
     E: Could not connect to client. :-(
     Log closed at 2012-08-26 11:17:42


The one success I have had looks like this:
     Log opened at 2012-08-26 10:34:33
     I: Checking remote connect back address.
     W: Remote address not found, connecting to configured address/port: 127.0.0.1:9000. :-|
     I: Connected to client. :-)
... {{ I deleted a bunch of stuff here that I can send later if anyone thinks it's relevant. }}
     Log closed at 2012-08-26 10:35:31


The XDEBUG settings in my PHP.INI file are as follows:
;
; MLM 4/16/2012 - added XDebug for use with VS-PHP to debug scripts (Zend Studio replacement)
;zend_extension = C:\UniServer\usr\local\php\extensions\php_xdebug-2.2.0RC1-5.4-vc9.dll
; MLM 8/23/2012 - updated to 2.2.1 version
zend_extension = C:\UniServer\usr\local\php\extensions\php_xdebug-2.2.1-5.4-vc9.dll
xdebug.remote_enable = 1
xdebug.remote_mode = req
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"
;xdebug.profiler_enable = 0
;xdebug.profiler_output_dir = C:\UniServer\usr\local\php\profiler
xdebug.idekey=MikeM
xdebug.remote_connect_back = 0
xdebug.remote_autostart = 1
xdebug.remote_log = C:\UniServer\usr\local\php\profiler\xdebug.log


I experimented with various versions of this at various times, but this is the most recent one. Notice that I specify the remote_host by number, and shut off remote_connect_back (= 0), but the log still shows connect back attempts.
I think the address ::1 is an IPv6 version of localhost (?), at least that's something I read in the Oracle VM docs once I believe. Not sure how standard that is but I'm trying not to use IPv6 on this VM. Or anywhere else lol.

So my question is how to get it to actually use the remote_host address that I'm providing, rather than using remote_connect_back as it seems to be doing, and getting that ::1 address, which doesn't work for some reason or other.

Can anyone help me, or direct me to where I can find out more about this problem?

I'd really love to get this working. I've finally hit a snag in my project that would be just SO much easier to debug with PHPStorm, and I'm loving the IDE in so many other respects.
That one time the debugger worked, I was in hog heaven too. Really nice! Can't wait to get this going again, and looking forward to a useful response.
Let me know if I've left out any relevant info.

I think that once I get past this, I may have problems with those bookmarklets too, and using the 'MikeM' IDEKEY instead of the numeric ones, but I'll get that going once I figure out that IP addressing issue.

Best regards,

Mike Mehr
new PHPStorm user (about to be very satisfied customer)
2 comments
Comment actions Permalink

Guess I should answer my own question here.
My problem was that I wasn't restarting Apache when I made changes to the PHP.INI, so it wasn't getting the version of host address I was supplying.
When I did this, things started to work, and I'm on my way.

Setting the record straight. And nothing quite so difficult as trying to figure out what your own fevered brain was thinking about a particular issue. I'm learning to write myself lots of documentation even though I'm the lone developer. Because I'm not sure what I'll remember next year, or even next quarter, about this!

Hopefully no one got caught up in spending any time on this.

Still not sure about where the '::1' was coming from, but it doesn't matter now.
I figure out the path mapping and then it just started to work again. On with the show!

Best regards,

Mike Mehr

0
Comment actions Permalink

Hi Michael,

My problem was that I wasn't restarting Apache when I made changes to the PHP.INI

That is a requirement when PHP is loaded as a module (the most common usage). If it's executed as FastCGI, then it's another story.

Still not sure about where the '::1' was coming from, but it doesn't matter now.

It's IPv6 -- if you do not use it (which is most likely the case -- it's extremely rarely used for virtual or home/small networks), just disable it in your connection settings.

Instead of disabling you can try this (works in most cases, cannot explain why it does not in other) -- add "127.0.0.1 localhost" entry to your hosts file (C:\Windows\System32\drivers\etc\hosts) even if the file says that you do not have to do it -- it will give IPv4 priority over IPv6 when resolving localhost.

I'm learning to write myself lots of documentation even though I'm the lone developer. Because I'm not sure what I'll remember next year, or even next quarter, about this!

Absolutely correct approach. Plus -- it will definitely help another dev who may take the project after you.

0

Please sign in to leave a comment.