I use VS Code and Tye (https://github.com/dotnet/tye) to run the set of .Net services. I need to configure the VS Code to attach to the service/process that was started by Tye.
I can configure the task in tasks.json to run the Tye with the service in debug mode. On run, Tye prints smth like the following /^.*Listening for event pipe events for my-servce(.*) on process id (\d+)$/
How to configure tasks/launch.json in VS Code to:
Run Tye and wait for the "Listening ..." string
As soon as the string is detected, extract process Id (Tye is still running)
Attach the debugger to the process Id extracted
On detach - terminate Tye
?
I have found that the easiest way to debug using Tye is:
Download/Install the VS Code extension.
Run tye run --debug *
Go to extension in VS Code and attach to service you would like to debug.
Related
In Visual Studio 2017 and 2019 on Windows, I run dotnet watch run in the Package Manager Console. It launched kestrel for a dotnet core app, automatically disabled text edit in the console, and displayed a red button to stop command execution, but the button doesn't do anything. Also, the message is being displayed to use Ctrl+C but it doesn't work either.
Now listening on: http://localhost:20436 Application started. Press Ctrl+C to shut down.
Now there is an error when I try to launch the web app in Visual Studio because it is already running.
I couldn't find a command like dotnet stop only Ctrl+C which doesn't work in this case. I used Process Hacker to kill the dotnet.exe process but that doesn't seem right. What would be the best way to kill the running process?
Since this stop option doesn't work it is clearly a bug. If I need to run dotnet watch run I generally just open command line on my current folder outside VS and run it from there. Since dotnet watch run has nothing to do with visual studio (no debugging) it makes sense. Alternatively, you can use the green button to run within visual studio with debugger. However, this would mean you can't edit the code while testing.
run your project:
dotnet run > Examplelog.log &
$ dotnet run > Examplelog.log &
[1] 162
end your project:
kill 162
$ kill 162
[1]+ Exit 127 dotnet run > Examplelog.log
So with kill[id] you can end your process.
you not need a second console and can use your console for other inputs (take note that all outputs will be stored inside the Examplelog.log-File you have to check)^^lg
when the service is already running just again apply build command "dotnet build" and then again run command apply like "dotnet run"
services will be up again then you just have to press Ctrl+c in the terminal to shutdown running services.
There is a red button next to the clear button in that section next to the project name. I just found it LOL I will show you a picture follow the yellow circle. I was trying ctrl+c too LOL
I'm new to jHipster, I've created APIs which are consumed by my application's front end. I want to debug my services but unable to attach debugger with IntelliJ.
My application starts by running command "mvnw" which is jHispter standard command when I opened this bat file in editor i found this :
#REM e.g. to debug Maven itself, use
#REM set MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
I setup MAVEN_OPTS environment variable but still it was of no use. I also tried to make a remote connection from IDE on port 8000 but still, it didn't serve a purpose.
Any help will be appreciated, thanks.
you can just run (in debug mode) the main method in the JhipApp Class (the SpringBootApplication Class). It worked for me
My tested and proven solution for debugging and then dividing the front end with the back ends, works for OS Windows and Ubuntu with the use of the latest version of the Ide Intellij Community (2020.1.1 used in both OS), provides that after creating a jhipster app (created with Ubuntu), from the command promp or from the Ubuntu shell launch the command: mvn -DskipTests = true clean install to compile the back end first and then the front end (in Angular 8 in my case), at the end of this compilation run the following command: mvn spring-boot: run.
After launching the application, click Ctrl + C and stop the run. Now you can launch the npm commands and then the command: npm start from the same command prompt or from the shell, since your project has been built and already launched it will be restarted and now from the Ide you can launch your class configuration annotated with #SpringBootApplication from the debug icon, at the end of the compilation you will have front ends and back ends divided and debuggable easily as well as hot changes for the front end take place quickly, while for the back end you will always have to save recompile and restart in debug.
You can do it, if you connect remotely, as you suggested in your question
Start jhipster in the terminal, but pass in some debug params
$ ./mvnw -Dspring-boot.run.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
Then you just connect to it using your IDE at port 5005.
For example, in Visual Studio Code
add a "launch.json" file
A "Add Configuration" button will be displayed when you have the launch.json as the active file in the editor. Click it.
Choose "Java: Attach by Process Id"
That will add a new configuration to the "Run and Debug" tab.
Click the "Attach by Process ID", button, and choose your process (port 5005 in this example)
Debugging will begin!
I am trying to setup a headless delve debugger that I can attach to remotely.
I am unable to find a way to launch a debugging server that doesn't pause the application I am debugging.
I have been using dlv attach --headless=true --listen=:2345 attach 32 but this pauses the process.
Alternatively I could use dlv --headless=true --listen=:2345 exec app if this allowed the app binary to run.
I don't know if the init file can do something like this? I cannot find any documentation on what that actually is.
If you consider delve issue 145, that might be a feature, not a bug:
I can't see the value of starting an actual debug session without pausing unless you're simply relying on providing an init file (to load breakpoints / tracepoints) and then want to immediately continue execution, which you could do by writing a continue command at the end of the init file.
You can already set tracepoints without stopping the program indefinitely with the trace subcommand, which takes a pid flag.
That being said, with Delve 1.3.0 (August 2019, 2 years later):
go-delve/delve issue 245 is resolved by PR 1585
cmd/dlv: add --continue to continue process on launch/attach
Add --continue option for attach, debug, exec, and trace, to issue a continue on start.
The main use case for this feature would be to start a headless delve server (for example within a container)
I would like to debug my revel application with Jetbrain's gogland built in debugger but gogland run configuration allowing to setup either package or file run scenario not debug process started by revel run myapp.
Now Gogland is Goland
I find official manual for create debug-config. I'll post here if you do not mind...
INTELLIJ DEBUGGING (GOLAND)
Create your project, for this example i will be using canonical “revel new github.com/myaccount/my-app”
“revel run github.com/myaccount/my-app” to generate tmp/main.go - this file is needed by intellij
Shutdown the running server
Create run configuration and in “Program arguments” add “-importPath github.com\myaccount\my-app -srcPath \src -runMode dev"
Point “File” to \src\github.com\myaccount\my-app\app\tmp\main.go
In “before launch” add “Run external tool”. There: Program: \bin\revel(.exe) Paramerets: build github.com/myaccount/my-app
It works for Linux&Windows
AFAIK, Gogland built-in debugger is delve.
I think you must try run debug with option attach:
Attach to an already running process and begin debugging it.
This command will cause Delve to take control of an already running process, and
begin a new debug session. When exiting the debug session you will have the
option to let the process continue or kill it.
Usage:
dlv attach pid [flags]
I don't have installed gogland now, but I had similar problem in past.
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.