问题
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.
回答1:
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.logRestart 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 :)
回答2:
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
回答3:
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.
回答4:
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".
回答5:
Possible reasons for NOT stopping at breakpoints:
- the IDE refuses 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 an other 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 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
来源：https://stackoverflow.com/questions/18315741/phpstorm-debugger-not-stopping-at-certain-breakpoints