remote debug with xdebug - unbound breakpoints

Posted November 15th, 2008 by lxa

I'm trying to debug remotely with XDebug 2.0.3 (dbgp $Revision: 1.125.2.4 $) on remote apache server. It seems that vs.php interacts with xdebug, and breakpoint is being hit (in xdebug log) - but still vs.php IDE marks breakpoint as unbound and does not stop on it.

here's debug output:

**********************************************************************
Start debug session 1

----------------------------------------------------------------------

my html here

----------------------------------------------------------------------
The thread 0x1 has exited with code 0 (0x0).

**********************************************************************

here's xdebug log:

Log opened at 2008-11-14 15:36:15
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///home/blankzakaza/www/index.php" language="PHP" protocol_version="1.0" appid="10040" idekey="5"><engine version="2.0.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2008 by Derick Rethans]]></copyright></init>

<- feature_get -i transaction_id -n supports_async
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="transaction_id" feature_name="supports_async" supported="1"><![CDATA[0]]></response>

<- feature_get -i transaction_id -n notify_ok
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="transaction_id" feature_name="notify_ok" supported="0"><![CDATA[0]]></response>

<- stdout -i 3 -c 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stdout" transaction_id="3" success="1"></response>

<- stderr -i 4 -c 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stderr" transaction_id="4" success="0"></response>

<- breakpoint_set -t exception -x "Fatal error" -i 5
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="5" id="100400001"></response>

<- breakpoint_set -t exception -x "Parse error" -i 6
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="6" id="100400002"></response>

<- breakpoint_set -t exception -x "Unknown error" -i 7
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="7" id="100400003"></response>

<- breakpoint_set -i 8 -t line -f file:///home/blankzakaza/www/index.php -n 8 -r 0
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="8" id="100400004"></response>

<- run -i 9
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="9" status="break" reason="ok"><xdebug:message filename="file:///home/blankzakaza/www/index.php" lineno="8"></xdebug:message></response>

<- stack_get -i 10
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="10"><stack where="{main}" level="0" type="file" filename="file:///home/blankzakaza/www/index.php" lineno="8"></stack></response>

<- run -i 11
-> <stream xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" type="stdout" encoding="base64">my html here</stream>

-> <stream xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" type="stdout" encoding="base64"><![CDATA[]]></stream>

-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="11" status="stopping" reason="ok"></response>

<- stop -i 12
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stop" transaction_id="12" status="stopped" reason="ok"></response>

Log closed at 2008-11-14 15:36:16

‹ debugger won't step .htaccess in projects ›

Comments

    As far as I know at least

    On November 18th, 2008 santanaNL said:

    As far as I know at least two of us already encountered the same issue with vs.php... I've started a similar thread and so did someone else.

    Unfortunately no fix seems to be available yet, what is taking so long?

    I've been looking at this

    On November 18th, 2008 webmaster said:

    I've been looking at this issue because the log looks just fine. It is interesting that VS.Php is not mapping the file correctly.

    I think I'm going to need to send you a debug build to get more detailed traces. I'll follow up via email.

    Thanks

    I'm having the same problem

    On December 5th, 2008 GregS said:

    Seems that maybe it's a problem of mapping from paths on my server (which xdebug reports) to paths via the network share (which is how the files are opened in VS). Is there a solution yet? If not, how can I help?

    We found a problem and there

    On December 6th, 2008 webmaster said:

    We found a problem and there is a fix in 2.6

    We are currently having an issue with uploading dev builds to the site. I hope to have a new build by tomorrow available at:

    http://www.jcxsoftware.com/jcx/vsphp-dev

    Tried it...

    On December 7th, 2008 GregS said:

    I've loaded build 2.6.2.5207, but it just hangs VS when I try to load my project. The status bar briefly shows the name of the project, but then it goes blank rather than showing individual file names, and the UI becomes completely unresponsive. I'll check back and try a later build when it's available.

    Greg, Is this a large

    On December 8th, 2008 webmaster said:

    Greg,

    Is this a large project?

    Thanks,

    Yes, there are about 2300

    On December 8th, 2008 GregS said:

    Yes, there are about 2300 files in it. Is it Intellisense going insane? Guessing your next question, I opened the project and left VS sit there for a while. After about 7 minutes it did eventually open the project. And hey, it hits breakpoints now! The breakpoint seems to get hidden after the first hit; the red circle next to the line in the editor goes away, and the right-click context menu gives the option to insert a new breakpoint, but it is still listed in the Breakpoints window, and it still stops on that line when executing. So, it's closer, but still not quite 100%.

    Seems like project-wide

    On December 8th, 2008 webmaster said:

    Seems like project-wide intellisense is screwing you up.

    After the first time, intellisense is cached so it does quickly. But it should do the parsing in the background.

    Do you have a dual core machine?

    Thanks,

    No luck on the "just the

    On December 8th, 2008 GregS said:

    No luck on the "just the first time". It continues to take 6-7 minutes to load the project every time. I have a dual-core laptop. The CPU usage mainly wanders between 10-15% during the load process (one CPU looks mainly unused, so I guess the other is at 20-30%), and the network (54Mbps wireless) is pretty steady. Just before the load completes, there's a spike where both CPUs go up to about 50% for a couple seconds. Not a lot else going on in the system at the time, so RAM usage is pretty low as well.

    A little more information.

    On December 9th, 2008 GregS said:

    A little more information. It takes all that time to load the project, then starts with "Parsing...." messages in the status line. Unfortunately, it is now crashing pretty often on me, when it hits certain files, or when I add files, or when I do the wrong kind of edit at the wrong place (e.g. hit "return" after a particular line) in the wrong file. Oh, and Intellisense is no longer showing me parameters for built-in PHP functions.

    Think I figured out why the

    On December 10th, 2008 GregS said:

    Think I figured out why the breakpoint appears hidden. It opens a second copy of the source file! This new copy doesn't appear tied to the project in any way; for example VS doesn't go to the correct location in the Solution Explorer window when it is activated, while it does if the original copy (which has the breakpoint set and still shown) is activated. Hope this helps.

    So which file it opens? Is

    On December 10th, 2008 webmaster said:

    So which file it opens? Is it opening the wrong file?

    As said by SantanaNL in this

    On December 11th, 2008 strikernl said:

    As said by SantanaNL in this post, it's a problem with the mapping of the files internally in xdebug versus visual studio(.php) because the files are being edited via a samba share.

    This is the relevant bit:

    The difference is that now my file has been opened twice in vs.php, my own "open action" from the solution explorer being "Y:\var\www\libs\blocks\Foobar.class.php" and the "open action" through xdebug being "Y:\var\www\libs/blocks/Foobar.class.php"

    I.e. xdebug seems to return paths with forward slashes (THIS is the important bit!) when hitting the breakpoint, and VS(.PHP) considers this to be a different file, thus not hitting the breakpoint in the original file!

    In essence it is the SAME file, but VS(.PHP) considers it to be a DIFFERENT file because of the forward slashes!

    I fixed the slash issue in

    On December 11th, 2008 webmaster said:

    I fixed the slash issue in VS.Php 2.6 dev builds.

    http://www.jcxsoftware.com/jcx/vsphp-dev

    In the next build, or the

    On December 12th, 2008 strikernl said:

    In the next build, or the current (i.e. 2.6.2.5210)?

    current build

    On December 13th, 2008 webmaster said:

    current build

    Had a chance to try this

    On December 17th, 2008 GregS said:

    Had a chance to try this today with 5210 (which reports as 5213 in the VS About dialog), and still having the same problem. Is there any other information I can give you to help track this down?

    Greg, Let me get through

    On December 17th, 2008 webmaster said:

    Greg,

    Let me get through this big change on project loading and we'll track this issue down.

    I'll send you a debug build so you can collect traces.

    Thanks for your patience,

    Juan