PHP Remote Debugging

Posted by ketema on 2007-08-23 09:07

OS: OS X

Hello. I have managed to get a remote php server to send debug to a debug proxy server and komodo on my local machine is successfully connected to and I can step through the php page. However when I am done the page never finishes loading in the browser, it just sits there waiting for a response. As a result all i ever get is a blank page.

Here are some vitals:

Webserver: Apache2, PHP version 5.1.6, Gentoo Linux, xdebug version 2.0.0

php.ini:
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=192.168.1.1
xdebug.remote_port=9000
xdebug.idekey=

config of gateway server:
has an external and internal ip. rant he following command:
python pydbgpproxy -i [external ip]:9001 -d [internal ip]:9000
got this out put:
INFO: dbgp.proxy: starting proxy listeners. appid: 4368
INFO: dbgp.proxy: dbgp listener on 192.168.1.1:9000
INFO: dbgp.proxy: IDE listener on 72.17.156.5:9001

when i tell komodo to listen it does, and the proxy server shows my connection. I also have a little output from ngrep capturing a web request that I appended the ?XDEBUG_SESSION_START= on the end of the URL:

response xmlns="urn:debugger_protocol_v1" xmlns
:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="36" status="stopped" reason="o
k">

that is the last line of output after I instruct the komodo debugger to continue with the page. Browsser never loads the page though.

Can any see what i am missing?

Thanks

I believe I have found my

ketema | Thu, 2007-08-23 10:06

I believe I have found my own answer. The python pydbgpproxy script is set up for local subnet, not true remote debugging or NAT. By running the command python pydbgpproxy -l DEBUG -i 72.17.156.5:9001 -d 192.168.1.1:9000 I am able to get the internal development webserver to send off the debug request and it shows up in my komodo, but komodo receives the internal ip of the proxy server and as such is never able to send back its responses. The solution would be to have the python pydbgpproxy script have a better understanding of its networked environment and recognize that if a debugger registration comes from an internal address that is should respond with its internal ip, but if the registration comes from an external ip it should respond with its public ip. This would allow true remote debugging. I am going to look into the pydbgpproxy script as well as investigate a local method of port and ip redirection. If any one solves this problem first please post your solution.

Thanks!

Re: pydbgpproxy

ToddW | Thu, 2007-08-23 10:38

You need to ensure the proxy key is the same for the php request URL and the Komodo debugger preferences. You might also want to specific the "xdebug.idekey=my_proxy_key" setting specifically in your php.ini file.

The pydbgproxy works like this:
1) Start the proxy server, which listens for connections on two different ports (one for php/xdebug and the other for Komodo).
2) Komodo, upon startup (or setting of the proxy configuration) will connect to the proxy server using the ip address and port, i.e. "72.17.156.5:9001" and specifies the proxy_key from Komodo's debugger preferences (I'll use "my_proxy_key" as my example proxy key).
3) Upon debugging a php page, setting the "?XDEBUG_SESSION_START=my_proxy_key" of the URL will cause the xdebug to connect to the proxy server.
4) The proxy server checks the proxy key supplied by xdebug with the known Komodo connections if a proxy_key match is made, it forwards the connection data on to Komodo using the already connected socket.
5) Komodo responds to the proxy with it's responses
6) The proxy server forwards along Komodo's responses back to xdebug.

If this is still not working, which version of Komodo are you using?

Cheers,
Todd

this is exactly how i have

ketema | Thu, 2007-08-23 11:48

this is exactly how i have it set up. My key is "ketema" in Komodo. the get string at the end of URLS is ?XDEBUG_SESSION_START=ketema. The connection from web server to proxy works and the page loads into Komodo just fine. I can step through the code just fine. However when the debugging ends, I would expect the page to load in the browser. It does not, just sits there spinning and waiting with no output.

It is as if Komodo is unable to tell the apache webserver, "hey were'e done, go ahead and send the output of the page now."

Komodo Version: 4.1.1 Just downloaded it yesterday.

additionally the reason i think its a networking thing is because in komodo if you look at debugger listner status the field called proxy client address list the internal ip of the proxy machine, when it should be the same as the Host Address just on the different port.

Ensure there are no errors

ToddW | Thu, 2007-08-23 11:47

You setup seems correct. Please check the Komodo log file to ensure that there are no errors occurring:
http://community.activestate.com/faq/komodo-file-locations#log_files

Thanks,
Todd

A bug with Xdebug

ToddW | Thu, 2007-08-23 18:07

This is occurring because Xdebug is not sending the correct shutdown data to Komodo, so Xdebug gets stuck in a "Shutting down" state, but never actually fully stops the debug session, waiting in a read state until the proxy is shutdown. Details and the patched "pydbgpproxy" can be found in this bug:
http://bugs.activestate.com/show_bug.cgi?id=70776

This updated proxy should be included in the upcoming Komodo 4.2.0 beta 7 (due before end of August).

Cheers,
Todd

XDebug updated in CVS

shanec | Thu, 2007-08-23 19:02

the XDebug sources are fixed and available from CVS at xdebug.org. Snaps will probably update soon as well.

thanks much

moshe weitzman@... | Sun, 2007-08-26 07:08

the new pydbgproxy fixed the problem for me. thanks.

Beta 7 now available

jeffg | Tue, 2007-08-28 21:58

Komodo 4.2 Beta 7 is now available with these fixes integrated.

--
JeffG