PhpStorm 2016.3.2, MAMP PRO 4.1, Xdebug 2.5.0, macOS 10.12.2 configuration trouble Follow
I have followed these instructions as closely as I can:
I'm attempting to debug a website running PHP in Chrome on the same Mac that is running MAMP and PhpStorm.
Relevant portion of php.ini:
I have a breakpoint set on the first executable line of a PHP script to be called from the website. 'Run -> Break at first line of PHP scripts' is off.
The Xdebug Helper extensions for Chrome is set up like this:
Xdebug Helper is set to `debug` for the target page.
Then I turn on PhpStorm's Xdebug listen:
In Chrome I refresh the page which generates this error in PhpStorm:
Debug session was finished without being paused
It may be caused by path mappings misconfiguration or not synchronized local and remote projects.
To figure out the problem check path mappings configuration for 'www.br.dev' server at PHP|Servers or enable Break at first line in PHP scripts option (from Run menu).
If I then turn off listening, enable 'Break at first line in PHP scripts', turn listening back on, and refresh the page in Chrome, I get the page waiting in Chrome, but nothing on PhpStorm. No errors, no changes, and no way to step through code.
What have I missed in my setup?
- PhpStorm 2016.3.2
- MAMP PRO 4.1
- Xdebug 2.5.0
- macOS 10.12.2
- PHP 7.1
Please sign in to leave a comment.
1) Please collect xdebug log (https://xdebug.org/docs/all_settings#remote_log) for such unsuccessful debug session and share it somehow (Pastebin/dropbox or alike)
2) Ensure that you have no Servers defined at "Settings/Preferences | Languages & Frameworks | PHP | Servers". If you have none -- then IDE should bring you some window to help setting it up. If you have some defined already (especially if done manually) -- possibly something needs to be updated there or it was done wrong from beginning.
My idea is -- you may have stuff breaking at file that is outside of project (so IDE is unaware of it) .. or something else .. and hopefully log will show it.
My xdebug log is here:
I did have a server defined at "Settings/Preferences | Languages & Frameworks | PHP | Servers" so I deleted it. When I turned listening on and enabled the debugger, after refreshing the page, PhpStorm asked to configure one which I did like this:
But the web page still hung and PhpStorm offered no step options.
After that the xdebug.log file was appended to and is the shared version.
I hope there are some clues in it to suggest the next steps.
Dropbox shows 404 for that link for me
Oops. Sorry. How about this one:
I do not see anything super obvious from the logs alone that would tell what is happening.
BTW -- how do you end actual debug session? It looks like you just killing it .. or it gets terminated itself somehow -- all 4 times.
From what I see:
1) First 3 sessions started at index.php (breakpoint was at line 12)
2) Last one started in sendgrid_send.php (breakpoint at line 3)
3) Only 1st session has more than 10 operations (communication packets between IDE and xdebug)
4) Is there anything special about those files? What kind of those lines are? I mean -- is that simple/one liners (one instruction per line) or it's some kind of multi-line array/function call etc)
5) Can you run this code using xdebug 2.4 (for that you need PHP 7.0 or 5.6)? If you can -- will it do any better?
6) Can you please also collect log from IDE side (How-to: Collecting PhpStorm/WebStorm debug Logs) -- to see what's happening there.
You can check idea.log in meantime to see if anything interesting is already located there (Help | Show Log in XXX)
7) If you have any watches -- delete them (to see if evaluating them is not what makes all this trouble)
8) Try debugging very simple script first: e.g. something among these lines(to simplify the environment/code so it's easier to see where the problem might be) :
If possible -- also try debugging them in CLI mode ("PHP Script" type of Run/Debug Configuration) -- this is to ensure that debug works in general (that it's not influenced by web server by any way -- although later is unlikely)
9) Will it work any different if you place programmatic breakpoint in your code instead of IDE breakpoints, e.g. by placing xdebug_break(); in your code on separate line)
BTW -- consider fixing this: "xdebug.remote_host=127.00.1" -- you have missed one dot -- it has to be 127.0.0.1
Right now I do not have other solid ideas. We may try TeamViewer session if you wish -- maybe I can spot something myself that way...
Lots to think about here. I am able to debug "as normal" with MacGDBp, so perhaps I have the server side set up properly.
I end debug sessions, so far, by turning off PhpStorm listening.
index.php is the main entry point for the website (driven by Grav NoDB CMS). sendgrid_send.php is the script I am wanting to debug.
index.php line 12 is:
sendgrid_send.php line 3 is:
The IDE log is at:
I don't believe I have any watches set.
I fixed the 127.0.0.1. That, by itself, didn't help.
I'll try debugging a very simple script and see what I get. And see what happens with a xdebug_break(); in the code.
MAMP PRO looks like it would be difficult to downgrade to Xdebug 2.4 - I'll wait on that until it becomes necessary.
Maybe a TeamViewer session would help. If nothing else works, perhaps tomorrow.
I tried an `xdebug_break();` in the code and that didn't help.
I created a simple script with a breakpoint on the first line, turned on debugging in Chrome, and turned on listening in PhpStorm.
But the problem continued. As soon as I sent the browser to the test page, the browser hung and PhpStorm did nothing.
Here are the logs:
Can we schedule a TeamViewer session?
Your xdebug log shows that debug session was ended normally this time (as compared to previous log).
idea.log did not showed anything debug related. Have you actually enabled that extra logging?
Try debugging this simple script in brand new empty project (in different virtual host as well, I guess).
What UK hours are you available tomorrow? I'm in East Coast USA time.
I'll double check the extra logging and try a simple script in a new project, in the meantime.
Extra logging is still set up:
It's too late for today (already past 00:30 here) .. but I will be online after 9:30 till 17:00 so may be able to find free time at that interval (no 100% guarantee for exact time slot). Otherwise -- after 19:00.