Debug mode is a neglectful parent and turns the breakpoints it ignores into zombies about vdebug HOT 17 CLOSED

Thanks for the detailed report, I knew exactly where to look to reproduce this.

It looks like this is a combination of two issues:

1. The breakpoint window error thingy
2. None of your breakpoints work

I've found and replicated 1, and 2 requires a bit more information from you if possible.

Could you try adding xdebug_break() somewhere in your code, where you want to set a breakpoint, and then re-run the debugging process? If it stops then we know there's a file mapping issue of some sort, and if it doesn't then there's an xdebug problem.

Thanks

from vdebug.

The latest commit should fix your problem with the exception being raised, so you can give it a go by checking out the dev branch on this repo. Cheers

from vdebug.

Sorry for the late reply! Had to get back to my work computer to replicate the problem properly. I'll check out the dev branch in a minute. For now, I can tell you that xdebug_break() was ignored just the same when I added it in my code.

Edit: I just checked out the dev branch. No exception, but the issue has assumed a new form: I am still unable to [conventionally] interact with breakpoints set prior to the debug process ending. The breakpoint window lists them, now, but moving my cursor over the line and hitting F10 only creates a new breakpoint with a different ID, occupying the same line. I can, however, manually delete the existing breakpoints with :BreakpointRemove

from vdebug.

Hi @qstrahl, check out issue #48 - someone else raised this as the primary issue. To make it easier for others to identify the issues I'll use #48 as the main issue for this. Feel free to post any extra info there if you like.

As for your break problem, it looks like there might be a problem with the Xdebug configuration since xdebug_break() didn't do anything. Try looking over your xdebug.ini to see whether it all makes sense. Can you step through, over, etc. when debugging?

If you're completely stumped, create a vdebug log with:

:VdebugOpt debug_file /path/to/vdebug.log
:VdebugOpt debug_file_level 2

Then start the debugger, create a few breakpoints, step over, blah blah blah, finish the session and attach the log (maybe as a Gist). We'll see where we can go from there.

Cheers

from vdebug.

This is my xdebug configuration, nothing strikes me as abnormal:

zend_extension=/usr/lib/php5/20100525/xdebug.so
xdebug.remote_enable="1"
xdebug.remote_handler="dbgp"
xdebug.remote_host="localhost"
xdebug.remote_port="9000"
xdebug.remote_autostart="1"
xdebug.overload_var_dump=0

I followed your instructions, here's the logfile output: https://gist.github.com/qstrahl/4996014

I also discovered that breakpoints are not ignored if they are created during the debug session - only if they are created before the session is started. Unfortunately, this means I have to break on entry and step over tons and tons of framework code to get at the stuff I actually care about, so this issue is still a crippling one for me.

Edit: I'm not sure if the logfile makes this clear so I figured I'd be explicit: yes, I can step over, in, and out just fine.

from vdebug.

Is there any other information that would be helpful to you? Any idea where the issue might be located?

from vdebug.

Hi Quinn,

Sorry, I haven't had a chance to properly look over the log file yet. I'm hoping to tackle this issue this week though, so I'll keep you updated when I know a bit more.

Thanks

from vdebug.

Awesome, thanks a lot! Let me know if there's anything else I can do.

from vdebug.

I've just taken a look through the Vdebug log file and it looks fine - am I right in thinking that you added all the breakpoints during the debugging session? If so, all I need from you is another log file where you simply do this:

1. Before the session starts, set one or two breakpoints
2. Start a vdebug session
3. Just a single step over/run/run to cursor - whatever you want
4. Exit

If you can give me that I think I'd be able to work out what's going on!

Thanks

from vdebug.

Followed your instructions, here's the log output: https://gist.github.com/qstrahl/5057293

Hope you can make sense of it

from vdebug.

Hi Quinn, thanks for that, it all makes sense. However, annoyingly everything looks fine! I can see that you tried setting 3 breakpoints, in the file /var/www/mopals/src/MoPals/Bundle/Controller/SurveyController.php, lines 676, 664 and 653. Xdebug returned and said they were registered.

I'm interested to know whether running to cursor works, if you were to go to the SurveyController file during a debug session and run to line 653 directly. Here's what you can do:

1. Open up the SurveyController.php file
2. Start a debug session, breaking on the first line - this will take you to the framework's starting script
3. Swap the buffer from this script back to the SurveyController (type :buffers to see a list, then :b<number> to choose a buffer)
4. Run to cursor with <F9> by default

If you could log that too, and post it as a gist that would be really helpful. Sorry, this is a bit of a pain!

from vdebug.

Done and done; it ran to completion without stopping: https://gist.github.com/qstrahl/5057450

Don't mention it, your dedication is much appreciated

from vdebug.

Hi Quinn, thanks. Again, it all looks as it should - breakpoints are being registered.

The final thing I can think of doing is setting up an xdebug log, so we can see what's happening there. Just add this to your xdebug.ini file:

xdebug.remote_log="/tmp/xdebug.log"

You will need to restart your web server (or fast-cgi if you're using that).

Then maybe follow the same steps as last time - running to cursor in the SurveyController. There should then be a section of the log that starts with <- breakpoint_set .... If you could paste that line and the following response that would be great.

Fingers crossed for a eureka moment...

from vdebug.

Well, this is all I'm getting from the log file:

Log opened at 2013-03-01 15:04:22
I: Connecting to configured address/port: localhost:9000.
E: Could not connect to client. :-(
Log closed at 2013-03-01 15:04:22

Just this message repeated a bunch of times. Also, the log seems to get written at random intervals; at no point during the debug session was it written to. As I was typing this message (a good minute after doing any debug stuff), the message popped up again in the log (I cleared it beforehand; I'm positive I didn't just miss it). I'm not sure what to make of this.

Edit: restarting apache fills the log with the error a bunch of times.

from vdebug.

This is so weird. The only thing I can think is that you have multiple Xdebugs installed, as there is clearly a connection being made with Vdebug. Did you install Xdebug with Pecl, a package manager or by compilation? Also, have you had any luck with other visual debuggers, or is it just Vdebug that's problematic?

If all other debuggers are the same then my only advice is to try re-installing xdebug.

from vdebug.

I can find no evidence of multiple or abnormal xdebug installation on this machine. Xdebug was installed with Synaptic the usual way, and other visual debuggers worked fine (at least with regard to breaking at breakpoints). I do, however, have some good news.

After restarting the computer I found it impossible to reproduce the problem, which is strange, because I restarted it before and it had no effect - perhaps one of your commits fixed the problem and a restart was required as well for some reason. In any case, I'm both unaffected by and unable to address this issue any longer. Thanks for the help.

from vdebug.

I'm glad that you managed to work around this! It's nice when there's a happy ending.

from vdebug.