I am trying to configure PhpStorm 2016.2 with Xdebug and Vagrant (Drupal VM). I have read many tutorials advising how to configure these three applications. I think it's almost there, but I'm not sure what this error is?
When I click to setup path mappings, it appears that 'File path in project' is the issue. On Vagrant I have:
/var/www/drupalvm/sitelog/index.php
On my local I have:
/Users/24ma13wg/PhpstormProjects/sitelog/index.php
...but I don't have index.php in my project files:
How can I resolve this? Thanks.
A
B
To solve the issue of needing to enable Force break at the first line when a script is outside the project can be solved by configuring PHPStorm to talk to the PHP Interpreter that is in DrupalVM.
Navigate to Preferences -> Languages and Frameworks -> PHP and click the ... next to CLI Interpreter. On the next window that pops up, click the + at the top and choose From Docker, Vagrant, VM, Remote. Choose the Vagrant Instance Folder by navigating to your local path to DrupalVM. Click OK on each of the open windows to close the options.
From here, you will just enable PHPStorm to start listening for new debug connections and will need to send a cookie along to allow to connect to xDebug.
I am running Codeception tests in a Symfony2 project and I am developing in PHPstorm.
Debugging codeception used to work, but i recently started a new project it doesn't anymore. Everything is configured as it should. When I set phpstorm to start listening for connections, and I set a breakpoint in bin/codecept. The debugger halts at the breakpoint (as it should).
But when I set the breakpoint in a test (which is definetly ran), I get the message
16:10:41 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 'null' server at PHP|Servers or enable Break at first line in PHP scripts option (from Run menu).
Do not show again (show balloon)
I do believe that something is going wrong with the path mapping, because my server is running on a symlink, but why does debugging app/console and codeception itself work, but not the tests ?
Probably because of this:
https://github.com/Codeception/Codeception/issues/1636#issuecomment-71205765
test is not executed directly, it is triggered from reflection.
I want to debug my test using Velocity and Mocha, using breakpoints and REPL instead of console.logs.
For debugging my app code I can start my Meteor app with the NODE_OPTIONS='--debug' flag, and then bind the debugger like node debug localhost:5858. This doesn't work for the mirror, although its log says debugger listening on port 5858 (both main app and mirror logs say that).
How can I debug it?
Use meteor debug instead of meteor run to start your meteor application. It will add the node inspector package to your running Meteor app so that you can debug it. Node inspector works by hooking into your running Meteor server
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
I added an XPC Service to my project and I would like to set breakpoints and inspect variable contents in the debug area in XCode. Breakpoints that I set in the service's code are not recognized (obviously, the debugger is attached to the main apps process. How and I attach the debugger (manually or automatically) to the XPC Service process after my main app launches it? Is there some way to run the service alone and send it messages without it being launched from the main app?
Debug -> Attach To Process -> By Process Identifier (PID) or Name...
Type in your XPC service process name. The next time launchd starts up your XPC service, Xcode will attach.
I am actually not sure how to attach the debugger. But you can still use "NSLog" for debug output on the console. Then start the "Console.app" in "/Applications/Utilities/Concole.app". Depending on your system language this app may have a different name (it's localized). It shows ALL NSLog outputs from all Applications which are running including your xpc-services.
It's not the debugger, but you will get informations out of your service.