Comments (17)
Thanks for the detailed report, I knew exactly where to look to reproduce this.
It looks like this is a combination of two issues:
- The breakpoint window error thingy
- 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:
- Before the session starts, set one or two breakpoints
- Start a vdebug session
- Just a single step over/run/run to cursor - whatever you want
- 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:
- Open up the SurveyController.php file
- Start a debug session, breaking on the first line - this will take you to the framework's starting script
- Swap the buffer from this script back to the SurveyController (type
:buffers
to see a list, then:b<number>
to choose a buffer) - 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.
Related Issues (20)
- Xdebug 3 support HOT 2
- xdebug 3 support HOT 1
- modern vdebug: does it play nicely with neovim and xdebug v3.0.2?
- nvim freezes on xdebug connection, then `Error starting Vdebug: <class 'EOFError'>` in the statusline
- Option to disable automatic updating of watch window
- No module found 'dbgp' but I am in a dbgp directory HOT 1
- VdebugEval! Can't get values of array at depth > 1 HOT 3
- Wrong reference in the VimPlug instalation at VimAwesome
- Python program stuck after debugging finish (cursor reach end of program)
- Infinite-ish recursion on singleton classes HOT 1
- No option with key 'autostart' HOT 1
- Vim hangs up connection without stopping on breaking point HOT 3
- Cannot expand or collapse HOT 1
- TypeError when empty xml elements in response HOT 1
- Are there plans for a new release?
- Update README PHP setup with Xdebug HOT 1
- Security concern
- Problems defining close keymap in neovim with lazy plugin manager
- Path maps not working HOT 1
- Error detected while processing /Users/***/vdebug.vim[343]..function Vdebug_load_options[8]..<SNR>11_DefineSigns HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vdebug.