My problem is, that the debugger always stops at the first breakpoint I set (doesn't matter where I set it in the code) but when I continue the execution it seems to jump to a random location in the code. Doesn't make any difference here if I use "step into, "step over" or "continue". I checked if any key on the keyboard is stuck but I can't find anything here and I also cleaned the browser cache and invalidated the PhpStorm caches. After some random time it works normally again and I can step around like I want.
The other weird part is, that it always jumps to the same random location from every set breakpoint, but every breakpoint got another random location.
I am using PhpStorm (latest Version) and Xdebug 2.7 for Remote Debugging with the following configuration
php.ini:
[Xdebug]
zend_extension="C:\xampp\php\ext\php_xdebug-2.7.0alpha1-7.0-vc14.dll"
xdebug.remote_enable=true
xdebug.remote_port="9000"
xdebug.remote_connect_back=true
xdebug.remote_autostart=1
xdebug.collect_return="0"
xdebug.profiler_enable=0;
xdebug.remote_log="D:\xampp\logs\xdebug.log"
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host = 192.168.1.129
PhpStorm:
I got this problem every 2nd or 3rd day at the moment for a few hours and just can't figure out what is going on.
Is there maybe a shortcut or anything like that, that I activated without knowing it?
So i just had the problem again and it seems that removing the watches (as suggested here: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000602950-XDebug-Remote-Debugger-seems-to-jump-to-random-locations) fixes it. I will keep an eye on this and post an update if the error occures again and removing the watches doesn't fix it.
Related
Is it possible that Pycharm 'save' the whole staus at a breakpoint and allow the customer repeat debugging from there?
Occasionally I may need to debug a complicate bug which need ~2 hours to reach the target function. The multi-process code consists of many nested invoking and loops. The narrowing down process is pretty tricky. The first breakpoint is easy to set up. But if the second breakpoint was not set up correctly. Or there was one more clicking on 'step over' button. The debug session may exit since there was error. That is terrible since I may need another two hours to start another debugging. If Pycharm allow me to 'save' the debug status at the first breakpoint and allow me back to there whatever the current session ends or not it will be great helpful.
If I could catch up abnormal result before the session exit, then I need to step back during Pycharm debugging to figure out the issue. I searched and found out that both visual studio and IntelliJ has this ability. 'Jumping to Cursor' in Pycharm looks a similar solution. So far I don't have a chance to verify it by using a complex case.
So in genearal, what is the best strategy to debug those bugs which take long time to reach the starting point but failure point/reason is unclear? Thanks a lot.
We have some library projects with a VPI extension. Defined in the DPR with library at start and {$E vpi} at end (Options > output settings > Application > Target file extension: vpi).
library appname;
uses
//...
{$E vpi}
Problem: When I run a debug in a VPI project it works only once. After any change it won't hit the break again. Now showing a "green" breakpoint when you run the app. The only way to get it back to work is by closing and open the IDE.
My Co-worker asked me if I have this problem last year, which I didn't. In his machine "when you change anything in your source, even a space in a comment, the break points won't work till you close and open the IDE again" he said.
We've compared lots of config from the IDE and we didn't find anything.
Now for some "no reason" my computer also stopped working with the debug.
I have looked into this topic "Delphi: why breakpoints from time to time are not usable (green highlighted line on IDE)?" with no luck.
I've tried the Clear unit Cache, un-check and check again the debug info, include TD32, include remote debug, uncheck optimization.
I've asked to other teams and they said that some machines works others don't. But they also don't know why.
Maybe someone here have another trick that may help.
I am having trouble using Xdebug with PHPStorm. I have searched Google, etc.
I have Xdebug setup on a remote host with my local files mirroring the remote host. I am using the Xdebug Chrome extension.
When I run the debugging through PHPStorm, it OPENS a file and shows a blue-highlighted breakpoint that does NOT exist at that file. It will stay there until I hit "resume" multiple times until I get to the file I actually want to debug. VERY annoying because then the session on Chrome timesout, so I can't debug.
I do not see any code that says xdebug_break(); and I never added a breakpoint to that file. In other words, there are no red markings at the left of the line numbers.
What is going on and how do I fix this? Has anyone else come across this problem?
I have tried skipping and ignoring the file ... still does not work! Yes, I have also viewed breakpoints through a separate window and it does not show the breakpoint that apparently exists.
Check the configuration on PHPStorm stop at first line property and disable it
After that go to Run >> Break at first line in PHP scripts
Try turning it ON and OFF few times. Sometimes it is get stuck in between: showing OFF but in reality it is ON.
This is a well known issue Read: https://youtrack.jetbrains.com/issue/WI-17389
I was having the same problem with my PHPStorm/xdebug config. It turned out I had the path mappings wrong when I mapped the root of the local file directory to the Absolute path on the server - Settings->Languages and Frameworks -> PHP -> Servers.
I fixed the mapping and the system is behaving predictably once again.
I've set up XDebug (2.2.1) and PHPStorm-IDE (Mac OS X 10.7.5) with standard LAMP stack for Mac OS (Apache 2.2.22, PHP 5.3.15).
/etc/php.ini
[xdebug]
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
xdebug.file_link_format="txmt://open?url=file://%f&line=%1"
xdebug.remote_enable = On
xdebug.remote_autostart = "PHPSTORM"
xdebug.var_display_max_data = 1024
xdebug.dump.GET=*
xdebug.dump.POST=*
xdebug.show_local_vars=On
xdebug.dump.SERVER=*
xdebug.dump_globals=On
xdebug.collect_params=4
I followed these two tutorials and it works in 99% of my project files:
http://blog.jetbrains.com/webide/2011/03/configure-php-debugging-in-phpstorm-2-0/
http://blog.jetbrains.com/webide/2011/02/zero-configuration-debugging-with-xdebug-and-phpstorm-2-0/
I use Zend Frameworks MVC architecture. I am able to stop at breakpoints in most of my controller classes, but in some other controllers PHPStorm ignores all of my breakpoints.
Do you have any suggestions? How can I debug the debugger? What kind of configuration error could cause that?
Thanks for your help.
This almost has to be the result of mismapped paths in phpstorm. You can configure paths in Settings->PHP->Servers. I ran into a similar problem and all I had to do was to set the correct absolute path on the server (where xdebug is running) in the mapping for the root of my code in phpstorm. e.g. c:\my\code\lives\here\on\my\dev\box => /myserver/my/code/lives/here/on/my/actual/server.
Here is a more complete solution, and some tips on debugging XDebug in general:
Add a remote log file to your xdebug settings: xdebug.remote_log = /path/to/logs/xdebug.log
Restart apache
Tail the log (I'm assuming you can do this in OSX)
tail -f /path/to/logs/xdebug.log
--You might see something obviously wrong by keeping track of the log contents the next time you try to debug a page. If so, just do whatever you need to do. If not, let's still assume it's a mismapping of paths and continue to try to fix that:--
Set a breakpoint where you know PHPStorm/XDebug will actually stop and make it stop there. In a lot of places on the web people report index.php being the easiest place to make PHPStorm actually stop at a breakpoint for the first time.
In a file that you can't get PHPStorm/XDebug to stop in, set and unset a breakpoint while PHPStorm is stopped at the breakpoint in the index.php file. You should see lines in your xdebug log file that look like this:
<- breakpoint_set -i 19 -t line -f
file:///myserver/my/code/lives/here/on/my/actual/server/file.php -n
159
->
See if the file actually does live where XDebug is looking for it e.g.
tail /myserver/my/code/lives/here/on/my/actual/server/file.php
If the file doesn't actually live there, adjust the path mappings in your PHPStorm settings until PHPStorm is telling XDebug to look at files that actually exist. e.g. if XDebug had said file=/mysrver/my/code/lives/here/on/my/actual/server/file.php, then in step 6 you would have noticed the file didn't exist on the server, and then you might realize "oh oops I spelled myserver wrong in the path mapping", and fixing the spelling in PHPStorm would then probably fix the issue.
This is a bit of an old thread but hopefully this will help someone eventually :)
OK, I had the same problem and dug around the PHPStorm bug tracking and also their dev forums.
It turns out that you need to make sure that the path to the file in which breakpoints don't work are exactly as they are (lower/upper case wise) on your MAC. I just migrated a project from Windows with mixed upper/lower case folders and file names on the drive and different cases in the require_once directives.
Once I made sure the path in the require_once matched the case on the disk, then my breakpoints started to work again!
See here http://devnet.jetbrains.com/message/5488439
This usually means the controllers aren't called.
If it does work for certain controllers (within the same project) it just means: the code wont get called.
So get a few steps up to see the correct controllers is called. (e.g. from the dispatch and then dive into until the controller gets loaded).
And is it possible that you work remotely (e.g. from local to another server). Than it can take a little time before it the code is placed on the server. Just wait a few seconds and than try again. Since how can it break on a point that it doesn't know?
Hope this helps to get you started to debugging it.
This happend to me too several times. Usually the debugger's configuration is the reason. You have to set the path mappings of the debug server correctly under "Run > Edit configurations".
Possible reasons for NOT stopping at breakpoints:
the IDE refuses the debug connection requests coming from the remote server. The telephone icon has to be green (Run -> Start Listening For PHP Debug Connections) in order to avoid this.
all the breakpoints are muted. Turn breakpoint muting off.
the Suspend checkbox of a particular breakpoint is not checked. Check them one-by-one in Run -> View Breakpoints. The tick means "Suspend Execution", not "Suspend the breakpoint", as one may think. (The current version of PHPStorm I use seems to be buggy, if I check the Suspend checkbox then it doesn't take effect yet. I have to click another breakpoint and then click back in order to "submit" checking the checkbox.)
If you want to debug a script invoked from a browser then the browser should set a cookie called XDEBUG_SESSION with the value of the idekey. You can initiate it by extending the URL this way: http://192.168.99.100/?XDEBUG_SESSION_START=PHPStorm. Be aware of the expiration of the cookie which is only one hour. There are useful browser add-ons for easing handling the debugger cookie. See https://xdebug.org/docs/remote#starting for more.
the individual breakpoint is not Enabled. Check them one-by-one in Run -> View Breakpoints.
the individual breakpoint has some condition that doesn't get met. Check the Condition setting of the breakpoint in Run -> View Breakpoints.
there is some mapping issue between the remote server and the IDE. When you set a breakpoint in the IDE then it sends the remote server that the execution should stop at the Nth line of the F file. There is a mapping between your local files and the files on the remote server. The mapping is defined in the IDE at the following places:
on the Path mapping field of the Preferences -> Languages & Frameworks -> PHP page
on the Preferences -> Languages & Frameworks -> PHP -> Servers page
If these mappings are incorrect, for example, the local F1.php is mapped to the remote F2.php by accident, then you may have problems. If you set a breakpoint at the line #N in your local file F1.php the server will stop the execution only if the execution reaches the line #N of file F2.php (rather than that of F1.php). If this is the problem then you still can debug your code if you turn on the Run -> Break at first line in PHP scripts flag. Be aware of the different case sensitivity in directory and file names of your development operating system versus that of the remote server!
The IDE is not receiving debug connection requests from the remote server due to some network setting issues. Check the Preferences -> Languages & Frameworks -> PHP -> Debug page whether the IDE is listening on port 9000 for XDebug, check whether it Can accept external connections, and so on.
The XDEBUG-related settings of the remote server are incorrect. I use the following settings in my php.ini
.
xdebug.default_enable = 1
xdebug.remote_enable = 1
xdebug.remote_connect_back = 0
xdebug.idekey = "PHPStorm"
xdebug.remote_autostart = 1
xdebug.remote_host=192.168.1.26
You should set remote_host to the IP address of your development computer, or you can omit the whole line if your server is on localhost.
Plus, I set the following environment variables:
export PHP_IDE_CONFIG="serverName=halmaiXdebug"
export XDEBUG_CONFIG="idekey=PHPStorm"
where the value of the serverName is the Name of the server I defined on the Preferences -> Languages & Frameworks -> PHP -> Servers page in the IDE.
UPDATE: Too old PhpStorm version also can cause breakpoint issues. With PHP 7.4 on the server and PhpStorm 2018.2 locally, the execution stopped at the first instruction but not at any further ones. After upgrading to a newer PhpStorm version (2020.1), it works as expected.
I have an app built in node.js and I use the node inspector in order to debug.
But it's quite hard because of this:
My breakpoints are never saved after I restart the server
I cannot put a breakpoint on a file that has not loaded yet; so I have to step into from the first script to the one I want; REALLY PAINFULL!
How do you really debug node.js with node inspector?
The videos on how to use node.js are quite misleading as everything is into a module...
http://www.youtube.com/watch?v=AOnK3NVnxL8
or this one the scripts appear are already loaded in the first script
http://www.youtube.com/watch?v=HJOH0-g8f6E&feature=mfu_in_order&list=UL
Edit:
Nobody can answer this question? :s
In javascript you can set breakpoints using the debugger; statement. However, they will only pause node if a debugger is actually attached.
So launch your node script using
node --debug-brk myfile.js
then launch node-inspector and press the play button to continue to the next breakpoint and it will hit your debugger; breakpoint (at least that works for me ATM)
(as noted in the comments: in recent versions of node you no longer have to separately install node-inspector. If you launch node using node --debug-brk --inspect myfile.js you get a url that launches the debugger in your browser).
you still need one extra click after restarting, but at least your breakpoints are saved.
if your breakpoint is not hit automatically, but only after some user action you don't need the --debug-brk of course.
The problem with client-side breakpoints is that it's hard to keep track of the breakpoint position when the file changes. Unlike in an editor, it cannot keep track of lines being changed, etc.
#RyanOlds suggestion of using debugger; statements is also a good one, but you have to make sure the debugger is connected before the statement is evaluated, because it is ignored otherwise. Starting with --debug-brk is a good way to force this, because the execution is paused on the first line allowing you to attach the debugger and then continue the execution.
You could try debugging with node's internal debugger.
Edit: However, according to the v8 DebuggerProtocol it's possible to set breakpoints on script that hasn't been loaded yet AND you can set breakpoints by function, script and more. It should therefore be possible for node-inspector to keep track of your breakpoints (in a session, or whatever). It doesn't do so right now, though.
Maybe if v8 allows a certain piece of code to trigger a breakpoint, similar to nodes debugger?
Edit: It does, you should be able to trigger a break by throwing any old exception (caught or uncaught).
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.
https://github.com/node-inspector/node-inspector/pull/116
Try using IntelliJ WebStorm - there's a free trial and licenses aren't outrageously expensive. It lets you save breakpoints in all your files prior to starting up its own internal node process and remembers them across process restarts.
I agree - node-inspector looks brilliant, but is quite useless unless your app has a clear place to set a breakpoint in the top level script just after your source files have loaded, but before you hit the area you want to debug. You can structure your own code this way, but you won't be so lucky with other helpful libraries you want to include. Also... why should a debugging tool dictate your project structure!
Forgetting breakpoints is extremely unhelpful... most of my debug runs take more than one walkthrough, as in other people's code it's easy to step past where you want to be.
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.
https://github.com/ketamynx/node-codein/
Also worth noting.. vscode has a great debugger for node.
https://code.visualstudio.com/
Available on Mac, Linux, & Windows.
It does runtime breakpoints (without the need of writing debugger; statements),
supports variable watches, and even has a call stack window (very nice).
Everything is so automated, it is now my goto over sublime text when using nodejs (and I LOVE sublime).
This is built in now including saving breakpoints. I just tested it in node 7.3.0.
node --inspect --debug-brk app.js
This prints a url like this
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/c3d5d93e-9d27-41b9-a4da-607e43c9d4f8
Put that in Chrome and you're good to go.
If you want to skip copy/pasting the url, do this:
npm install -g inspect-process
inspect --debug-brk app.js
Unfortunately the inspect-process method doesn't retain the breakpoints :-(.
Here's a video I made: https://youtu.be/rtZKUnks6jI