Before each debugging cycle I have to run gdbserver on remote target (Linux). So I was thinking to make script that would call python program that would connect over ssh and would run gdbserver.
I cant find any options to run command before debug and I also try to change .gdbinit file but I am unable tu run python script whit that. Since I am using crosscompiler I cant to get other gdb whit such support.
You don't need to run Python to invoke an external command from GDB. This (in .gdbinit) should work:
shell ssh remote-host gdbserver :12345 /path/to/binary/on/remote &
target remote remote-host:12345
If you do need more complicated ssh setup and need Python for that, you can certainly get it with
shell python your_script.py
If you can't get any external program called from your gdbinit, I see one way of doing it within Eclipse that might work (I didn't tested) but it is not really straightforward...
Create an External Tool configuration that launches your gdbserver program (Python or whatever command line script)
Create a C/C++ application launcher that launch your application to debug
Create a launch group that will call the two previously configured configurations.
Launch the group in debug mode
Eclipse 4.7.0 can connect to SSH and launch gdbserver automatically with the automatic launcher set when creating a new debug connection, without the need for any custom scripts.
I have explained the setup in great detail at: Remote debugging C++ applications with Eclipse CDT/RSE/RDT
What's the easiest way to debug Scala code managed by sbt using IntelliJ's built-in debugger? The documentation from "RunningSbt" from sbt's google code site lists commands for running the main class for a project or the tests, but there seem to be no commands for debugging.
Follow-up question: what's the easiest way to attach IntelliJ's debugger to Jetty when using sbt's jetty-run command?
There's a very convenient -jvm-debug flag in the official SBT packages for Mac, Linux & Windows. You can use the flag to specify the debug port:
sbt -jvm-debug 5005
Under the covers, this starts the JVM for SBT with the typical verbose debugging incantation:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
You now can run your code as normal, for example with the sbt run command.
Configuring IntelliJ to connect to the running code...
Now you connect IntelliJ to your running process using a Remote Debug configuration. Note that the upper 3 fields in this form, while scary, are just for you to copy text out of, rather than into (they're giving the verbose debugging incantation specified above, which -jvm-debug already takes care of for you) - the only configuration you can change is in theSettings section halfway down:
For ordinary debugging in IntelliJ, you can use an Application run/debug configuration in the usual way, regardless of whether you're using sbt to compile your code.
To connect to your application running in Jetty, you'll need to create a Remote debug configuration. When you do so, IntelliJ will give you a set of command line arguments for running the remote JVM -- something like
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Launch sbt with these arguments and then execute jetty-run. Finally, launch your remote debug configuration in IntelliJ. This thread might be useful.
I had some trouble with this too, so at the risk of being overly detailed, here's what I did:
SETUP
Create a run configuration for sbt jetty-run
Go to Run > Edit Configurations
Click the [+] icon and choose Scala Compilation Server
Enter whatever name you want, and click the "Run SBT Action" checkbox and select the SBT Action jetty-run from the [...]
Create a debug configuration for remote debugging
Go to Run > Edit Configurations
Click the [+] icon and choose Remote
Enter whatever name you want and copy the line -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 (make sure to click OK to actually create the configuration)
Set up sbt plugin to run the vm options above
Go to File > Settings > SBT
Paste the line -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 in the VM parameters box, after the ones that are already there
DEBUGGING
Set breakpoints as desired
Start the jetty web server by choosing the sbt jetty-run configuration you created above and choosing Run > Run or by clicking the green arrow
Start the remote debugger by choosing the remote debugging configuration you created above and choosing Run > Debug or by clicking the bug icon
This one works for me every time, and the only thing you need to set up is remote debugging in IntelliJ; I start up SBT with JVM parameters from the terminal in IntelliJ:
sbt -J-Xdebug -J-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
After that I can start remote debugging on localhost:5005
None of these answers or provided links worked for me, so once I figured this out, I figured I'd share...
including the background understanding I didn't have when I started...
This is based mostly on the instructions here just with additional explanation that carried me through it.
My Environment:
Scala 2.10.2, SBT 0.13, and IntelliJ 13.1
Background:
For whatever reason, using SBT to compile Scala in IntelliJ isn't integrated the way Maven projects are (which allow debugging really easily).
It appears from my understanding that when compiling with SBT, you're compiling in a separate process, therefore, you need to be remotely debugging.
What is Debugging?
Debugging is a mode you can run your JVM or app in that allows you to control the flow of code execution.
The Debugging Tool you use can then issue commands to the Debugging Engine that tells it "execute the next line of code then pause again" or "continue executing" or "get the value of the variable stored here in memory".
What is Remote Debugging?
Remote Debugging is debugging over a network connection (socket).
This network connection allows you to issue the commands to the Debug Engine from a remote machine.
This is useful for when you want to debug code that's running on a remote server, BUT
It's also useful for situations like Scala code running under SBT and launching via a web server, such as Jetty or Tomcat, separate from your IntelliJ environment.
Referencing the link above, the following explanations/modifications are useful:
Setup IntelliJ to launch SBT with the "enable debugging" JVM settings, including the port to use when setting up the network socket. (unchanged) add the named VM parameters to your IntelliJ settings.
Ensure your port number here matches your JVM settings from Step 1.
When you launch SBT, you need to do it from the SBT Console plugin (which is what you configured in Step 1). If you're running SBT outside of IntelliJ (at the commandline), you'll need to launch SBT with the same VM parameters from Step 1 (I didn't do this; so no instructions). After this step, SBT is now running (but your code is not yet) and the JVM is setup for Remote Debugging.
This starts the IntelliJ Debugging Tool, which connects to the JVM you started in Step 3.
Finally, you start the compilation in the SBT Console. You can do this with any compilation command, including a continuous compilation command. If continuous re-compile, the recompile will happen, but not while code execution is paused by the debugger.
I am adding another answer here, because I found this question when looking up a related problem: Debugging test classes using breakpoints.
I am using ScalaTest, and I typically run a suite using sbt's 'test-only' command. Now when I want to use the interactive debugger, I can do the following:
Create a new Run/Debug Configuration of type 'ScalaTest', put the main "Test Class:" name, and choose "Before launch: Run SBT Action 'test-compile'". That's it, you can place breakpoints now in the test sources, and run this configuration.
I've been struggling with debugging too on Windows with a Spray-can / Akka / Scala app built via SBT, using Intellij. Piecing together various suggestions, the simplest approach for me was:
Make sure you have sbt.Revolver in your project/plugsin.sbt file e.g.
addSbtPlugin("io.spray" % "sbt-revolver" % "0.7.1")
Set javaoptions in you build.sbt file:
javaOptions := Seq("-Xdebug", "-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005")
In particular use the suspend=y option. This will hold the app until you connect a remote debugger from Intellij
Set up a debugger configuration in Intellij via Run / Edit Configurations menu. Press the + button, select the "Remote" option. Make sure the entries match the javaoptions above, in particular the port address of 5005. Give the config a name like 'Spray'.
From your SBT console use the re-start command. You should see the 5005 port address in the feedback output.
In Intellij set your breakpoints.
From Intellij, select the Run \ Debug 'Spray'. This should connect to the spray-can web server. You should be able to see a lot of threads in the debug window.
Beware that some of the Get directives in Spray seem to get executed on start up but not repeatedly on calling the website.
File->Settings->Other Settings->SBT
VM parameters
-Xmx512M -XX:MaxPermSize=256M -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Run->Edit Configurations
Press + and then select remote
Press Apply
Now in the SBT console (Started inside by intelliJ) when you execute the command 'run' You will see "Listening for transport dt_socket at address: 5005"
Now press Run->Debug. You will see the debug menus below activated. It has two tabs Debugger and Console.
Use F7 to from next line to next
I chose suspend to be n. With it being y when I ran the run command it was stuck
export SBT_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5009
try this
For what it's worth Windows folk, edit %SBT_HOME%\bin\sbt.bat and locate the following lines of code:
:run
"%_JAVACMD%" %_JAVA_OPTS% %SBT_OPTS% -cp "%SBT_HOME%sbt-launch.jar" xsbt.boot.Boot %*
if ERRORLEVEL 1 goto error
goto end
then replace them with this code:
FOR %%a IN (%*) DO (
if "%%a" == "-jvm-debug" (
set JVM_DEBUG=true
set /a JVM_DEBUG_PORT=5005 2>nul >nul
) else if "!JVM_DEBUG!" == "true" (
set /a JVM_DEBUG_PORT=%%a 2>nul >nul
if not "%%a" == "!JVM_DEBUG_PORT!" (
set SBT_ARGS=!SBT_ARGS! %%a
)
) else (
set SBT_ARGS=!SBT_ARGS! %%a
)
)
if defined JVM_DEBUG_PORT (
set _JAVA_OPTS=!_JAVA_OPTS! -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=!JVM_DEBUG_PORT!
)
call :run %SBT_ARGS%
if ERRORLEVEL 1 goto error
goto end
:run
"%_JAVACMD%" %_JAVA_OPTS% %SBT_OPTS% -cp "%SBT_HOME%sbt-launch.jar" xsbt.boot.Boot %*
goto :eof
Best I can do to get same behaviour for -jvm-debug when seen in the Bash script launcher
NB. I don't think %SBT_HOME% actually exists outside this script, unless you created explicitly in you environment, but anyway you get the point :D
AttachMe IntelliJ plugin is potentially faster way off attaching the debugger without having to fiddle with port numbers:
AttachMe will attach the IntelliJ debugger automatically even if you
start your app from terminal (or any other way). You don't need to
trigger Attach to process action manually.
Blog post and readme have setup instructions, however I had to alter them a bit to get it working on my machine
Download installer.sh script from official repo
curl -o installer.shhttps://raw.githubusercontent.com/JetBrains/attachme/master/installer.sh
Give it executable permissions chmod u+x installer.sh
Run it with ./installer.sh
This should install the agent under /.config/attachme/agent.jar and create ~/.attachme file
Modify ~/.attachme to contain
AM_JDWP_ARGS="transport=dt_socket,server=y,suspend=y,address=127.0.0.1:0"
echo Using JDWP arguments ${AM_JDWP_ARGS}
export JAVA_TOOL_OPTIONS="- javaagent:/Users/mario_galic/.config/attachme/agent.jar -agentlib:jdwp=${AM_JDWP_ARGS}"
echo "AttachMe configured successfully"
Install corresponding Attachme plugin and restart: IntelliJ | Preferences | Plugins
Create Attachme run configuration: Run | Edit configurations... | Add new configuration | Attachme debugger registry | OK
After these one-off shenanigans, we can attach a debugger automatically by
Start Attachme run configuration
source ~/.attachme
Start application from terminal, perhaps, sbt "runMain example.Hello"
The debugger should automatically attach and stop at any breakpoint
I also got the same problem, I like to share how I resolved. By the way I am using Ubuntu 14.04 and IntelliJ 15.
In Setting -> SBT ->
Pasted below line in VM Parameters text box:
-XX:MaxPermSize=384M -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Opened Termilal in IntelliJ and run:
sbt -jvm-debug 5005
Note: you should see this line in terminal: "Listening for transport dt_socket at address: 5005"
Edit Configurations -> Click + -> Select 'Remote'
I. Give some name example: DebugMyModule
II. All needed configurations will be set automatically, But you just verify. In Command line arguments should look like this "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005".
III. In 'Search Sources in Module's Classpath' text box specify your module in which module your test cases are there.
IV. put 127.0.0.1 host instead of 'localhost'. 'localhost' not working for me.
Select DebugMyModule in Edit Configurations list box and click Debug.
Note: You should see Debug View opened and in Debug Console You should able to see "Connected to the target VM, address: '127.0.0.1:5005', transport: 'socket'"
Put breakpoints in few test cases in your Testclass.
Come to Terminal where you run "sbt -jvm-debug 5005" and run like below
project <your-module-name>
it:testOnly package.TestSpec
For example: com.myproject.module.AddServiceTest[Spec]
You can see debug started in your test case breakpoint.
Give a cent step by step regarding a relatively new version of Intellij (2020.1.4):
Configure Intellij
"Edit Configurations"
Add "Remote"
This new version of Intellij does not allow you to edit the string in the "Command line arguements", you can only edit the "Host" and "Port" above, which I leave it default; I only change the "module path" below to "root" (not sure if it's necessary)
Remote debug
Set your break point
Execute sbt command in command line, e.g. sbt -jvm-debug 5005 test
Immediately go back to Intellij and click on "Debug", it should show something like "Connected to xxx", then wait till it suspends at your break point
As per Roberto Tyley's answer above, but in Windows we also need to set the following environment variables after installing sbt:
SBT_HOME
C:\Program Files (x86)\sbt\
[or wherever sbt is installed]
SBT_OPTS
-Xdebug -runjdwp:transport=dt_socket,server=y,suspend=n,address=5005
[per RT's IntelliJ example]
Add to path: %SBT_HOME%\bin;%SBT_OPTS%
Then run the following in the command line within the project folder
"sbt run -jvm -debug 5005".
If this is working properly, the command line will initially output a line re
"Listening for transport dt_socket at address: 5005".
Set breakpoint in IntelliJ.
Open website in browser to trigger the debugger breakpoint e.g. "http://localhost:9000/".
I'm currently writing some ncurses code and the native Eclipse (3.2.2) console can't display its graphics. I'd instead like to run the program through xterm. What I want is to be able to start xterm and run from there. I'd prefer to not get involved with any plugins or that jazz. Just something simple.
EDIT
So I have the answer and it was pretty simple...
Run -> External Tools -> External Tools -> New Launch Config...
Then select location of your terminal emulator. /usr/bin/gnome-terminal in my case.
after that set the appropriate arguments. "-e ~/ncurses/start" in my case.
Then make sure you aren't allocating a console by unchecking that option in the "Common" tab.
Annon add to his question:
its a pain to keep switching back and forth from eclipse and the terminal. I'm looking for a way to just hit something like"F5" and have it run my ncurses program in a new xterm terminal process
The simplest way to do that is to report the command line into an external tool configuration, and point eclipse to use a shell (like described in this program)
In the argument, you will add the command line eclipse execute (command line which can be retrieved as mentioned in the second part of this answer below).
Of course, replace 'cmd.exe' by the shell of your choice, and try not setting the 'Allocate Console' checkbox in the Common tab of that external launcher.
To launch through a xterm, without eclipse involved (not what you are asking for, just keep here for archive)
You can launch your program through Eclipse (Run Configurations), and observe through a 'ps' command the exact Java command line used.
Or launch it in debug mode, and right click the task in Debug view and open Properties. It will show the command line, as documented here.
Then launch that command line directly in your console (Eclipse being not involved at all at this point).