I have been trying to remotely debug an application which can only be run on a specific server because of hardware limitations. To normally run the program I would login to an ssh shell with X.11 forwarding enabled (-X option of ssh) and its QT interface will show up.
I have been trying to achieve the same but with no success while debugging via gdb with the gdbserver and the integrated gdb client of Eclipse IDE.
Is there a way to achieve this?
I have already tried to copy the settings of the system variables DISPLAY and XDG_RUNTIME_DIR of an ssh -X session (the later being empty) but with no success. Searching for it gives no relatable results (or I may need a hint on what to search).
It's not the cleanest solution, but you can manually set the DISPLAY variable in /etc/environment. Variables set in /etc/environment are available to the entire system. You'll need to reboot the server before gdb will see it.
See: https://help.ubuntu.com/community/EnvironmentVariables#A.2Fetc.2Fenvironment
Here's a one-liner to append your current DISPLAY variable
echo "DISPLAY=$DISPLAY" >> /etc/environment
I've been trying to debug a phoenix application.
To do so I used the following instructions:
- To set a break point: require IEx; IEx.pry
- To start a debugging server: iex -S mix phx.server
The problem comes when starting the server, the above instruction leads me to the elixir interactive shell (iex(1)>) and does not allow the server to run, from here if I execute the code manually it stops in the prys but I was hopping to have the server running and stop whenever a request hit the pry. Is there any solution?
I am currently using earlang 1.20, elixir 1.5 and phoenix 1.3
It is common behavior that the iex -S mix phx.server command opens an IEx shell. It runs the web server on the port configured for the Phoenix endpoint within the respective MIX_ENV simultaneously to that. For each IEx.pry() breakpoint it executes, it should prompt on the command line whether you want to open an IEx shell there.
Check which MIX_ENV your server is running in, e.g. by typing the following in the IEx shell:
Mix.env
And then find the configuration in the files within the config/ directory. The line should look like this:
config :nameofyourapp, Web.Endpoint,
http: [port: 4000],
Maybe something other than 4000 is configured there? Or maybe some other application, or even a previously started instance of your web application already listens on that port and therefore prohibits the debug server from binding on that port? In that case, shutdown other running mix phx.server processes.
I'm trying to setup PhpStorm to debug correctly within a Vagrant Homestead environment. Xdebug is correctly installed and I'm running PHP 7.1
After setting a breakpoint in my app the script passes through any breakpoints and I get this message:
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 'wedleague.loc' server at PHP|Servers or enable Break at first line in PHP scripts option (from Run menu).
I've checked the mappings and have this set up for the root of the project:
local path remote path
file://C:/vagrant/projects/wedleague /home/vagrant/code/wedleague
If I set to debug at first breakpoint I can work through the debug session.
Tried loads of answers here but nothing seems to work.
What can I try to get the debug session to work correctly?
Update:
I've also tried this mapping (as suggested)
file://C:/vagrant/projects/wedleague/public /home/vagrant/code/wedleague/public
Still not working with this configuration either :(
Step 1
Install PHPStorm 2017.X
Install Xdebug helper for chrome
Step 2
Via ssh (choose a tool like putty, WinSCP, MobaXterm etc.)
Install xdebug, in your case laravel gets Ubuntu 16.04 by default with Nginx so we need to follow these instructions
The values I used are
; Enable xdebug extension module
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.remote_host=10.0.2.2
in /etc/php.d/xdebug.ini
But note that I use my own vagrant installation (homestead is based on Vagrant) with CentOS and apache instead. Restart your virtual machine after config changes.
vagrant / homestead halt
and start again
vagrant / homestead up
Step 3
Config Xdebug helper extension in chrome by right clicking the symbol > options and set your IDE key to PHPStorm in the dropdown menu.
Configure PHPStorm, like a lot
hint: Settings has the shortcut ctrl + alt + s
Check the following settings. Don't forget to add both http and https in the Servers Setting and most important, don't read over the path mappings part.
And last but not least click these buttons, the first button with the phone horn actually has reversed icons in my opinion: when debugging it should have the little green part, altough logically red would mean stop, now it means start.
button 2 starts your url with a session var in the query string!
P.s. from your question: I think you need to go 1 level up root of laravel instead of public folders
edit: I just installed homestead at home and it comes with xdebug installed:
I want to start Apache in Mac. If I make web sharing enable by checking in system prefs -> web sharing, Apache works. But if I input command in terminal: sudo apachectl start, Apache doesn't start. In this case, when run http://localhost in Safari, it always said The requested URL / was not found on this server. In both cases, I used the default httpd.conf.
Therefore, How can I start Apache and make it work in Mac by inputting command in a terminal instead of by the graphical config window of mac itself? I prefer to command in a terminal.
Thank you.
Figure it out. The point is from the words of /etc/apache2/httpd.conf:
The <IfDefine> blocks segregate server-specific directives
and also directives that only apply when Web Sharing or
server Web Service (as opposed to other services that need Apache) is on.
The launchd plist sets appropriate Define parameters.
The action of Web Sharing in mac (system prefs -> web sharing) in nature first launches plist to set appropriate Define parameters, then calls apachectl. If we read httpd.conf, we can find the file is structured in several sections -- <IfDefine xxxx>yyyyy</IfDefine> based on the parameters from plist.
If we call the command sudo apachectl start in terminal like what we usually do in linux, the Define parameters from plist can't be set. Although httpd is up, it is not configured appropriately, e.g., in my case, DocumentRoot is not set at all because the parameter is surrounded by
<IfDefine !MACOSXSERVER>
<IfDefine WEBSHARING_ON>
DocumentRoot "/Library/WebServer/Documents"
</IfDefine>
</IfDefine>
This is why the error log said [error] [client 192.168.1.2] File does not exist: /usr/htdocs. As to /usr/htdocs, it is not set in any configure file but is hardcoded in Apache. It is the "last resort" place to look for.
If we comment #<IfDefine !MACOSXSERVER> and #<IfDefine WEBSHARING_ON> and the two #</IfDefine>, call sudo apachectl start in terminal. Then everything is ok.
It took me a full day of work to finally straighten this out. I hope it is useful to those guys who are used to be Linux and especially prefer to command line in terminal like me and just move to Mac.
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.