I just started with the Play Framework but to learn these kind of things it is amazingly convenient to be able to use breakpoints.
Now I figured quickly that when I run 'activator -jvm-debug 9888' I can connect my Intellij CE 14 to its debugger. That seems to work, console gets nicely printed on the webui 'standard out' but not in my Intellij even when it says it connected.:
'Connected to the target VM, address: 'localhost:9888', transport: 'socket''
But that is truly about it, no console messages are show or breakpoints get hit inside intellij
Anyone had the same problem before and knows how to solve it? (Googling didn't find me the answer!)
Greets
In your build.sbt try to add this line (with a capital T!):
fork in Test := false
For info see http://www.scala-sbt.org/0.13/docs/Forking.html
Related
I have problems for some time with debugging in Intellij (Ultimate 2019.2).
If I set Breakpoints and restart Intellij, or it reloads after a code change, all the Breakpoints work as expected:
But if I set the Breakpoints when the Play server is running, only a few of them still work:
Is this a bug, or is my configuration wrong?
Try this
File -> Invalidate Caches/Restart
Intellij keeps reloading stuff, breakpoints become active only when it's truly sure, no false positives here.
Usually I do, start the server then debugger and make sure endpoints are active before I make the request.
As it worked with plain sbt (Thanks for the hint of #Gagandeep Kalra), I asked for support of Intellij:
https://youtrack.jetbrains.com/issue/SCL-16565#comment=27-3792469
I'm working with Stainless, a software verifier for Scala programs. I would like to debug the verification process of a sample programme on Intellij Idea. On a previous post, I solved this integration problem for an interactive theorem prover. But now, I'm facing two problems:
Apparently, the verification software runs at compile time. That is, I enter in the sbt console and run the compile command and then the verification process seems to be done. You may try this with this verified example. This situation is new to me, since I was used to debug the program while executing.
All the setup in the sbt files of the example above (see for instance this file) seem to refer to online content, while I want to make sure that I work with my local copy forked from the original repository of the verifier.
None of the configurations I tried worked. Can you help me out of this problem?
Details
This is the current configuration page of stainless.
If the verification runs within the sbt process, you can debug it by attaching the debugger to sbt. IntelliJ makes this easy with the embedded sbt shell:
open the sbt shell toolwindow
click the "attach debugger to sbt shell" button on the left
set breakpoints in your code
run the task
I've been having trouble lately with getting GWT dev mode to work. First I haven't been able to get IntelliJ 13 to work with dev mode on Mac, though it does work on Windows.
However, with the Firefox 27 release, the dev mode plugin no longer works. Apparently, this is going to be a permanent problem. And Chrome is soon to follow as Google will no longer be allowing access for those types of plugins.
So, the solution is supposed to be to use Super Dev Mode. However, as I said, I can't get this to work at all. I've tried through the IntelliJ IDE, but it looks like they've removed the Super Dev Mode checkbox when creating a new debug configuration.
So, I tried on the command line. Looks something like this:
java -cp $CLASSPATH com.google.gwt.dev.codeserver.CodeServer -port 6667 -workDir ~/gwt-work -src ~/src/myProject/src/main/java org.foo.myProject.web.MyProject
But, all I get is a stack with this:
[ERROR] Unable to find 'com/google/gwt/user/User.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?
Classpath has all the jars from my project WEB-INF/lib directory as well as all the gwt SDK jars. I'm kind of at a loss right now.
TL;DR How the hell do you get Super Dev Mode to work?
Here is great answer related to super dev mode. Check this out
Getting started with the SuperDevMode
This should solve your problem
Hello all: I have never posted on Stackoverflow, but I have always come here for help for years.
I have a question and problem regarding debugging in eclipse using an STLINK STM32 Discovery board. I have looked online for the answer and have followed many tutorials, but I still cannot seem to get it to work correctly. I will try my luck at asking here.
I have set up the eclipse environment correctly with my compiler and gdb server (to my knowledge). First I make sure the server is started before I press debug in eclipse. I am using Atollic STLINK gdb server. I have tried many arm-none-eabi-gdb type exe's while debugging, but they all seem the same. My debug configuration is setup to use arm-none-eabi-gdb on port 61234 (Attolic). When I press debug, the program launches correctly and goes into the debug view in eclipse. The program downloads correctly to my discovery board. I know this because I have gotten debugging to work partially and have stepped through the code without crashing on 'some' occasions depending on the compiled code and debug configuration startup options. The code is a simple LED turn on on the board. If I unplug the usb cable and plug it back in, my code runs fine, because the LEDs light up, so we know the environment is probably set up correctly, because the code downloads to flash via eclipse commands.
The problem is with actual debug steps. 99% of the time the arm-none-eabi-gdb.exe program crashes when in the debug view after I do a few "step into's" with the debugger commands at the top of eclipse. After the first line of my main function is reached, I will try to step into the first line and I get a windows crash of the arm-eabi.exe program. The debug console in eclipse reads a gdb error: .......dwarf2: C10xx Internal Error - unknown CFA rule. Now... depending on how I set the options in the debug configuration with regards to the startup tab, different options produce different results and the following options have been toggled: Halt, resume, break point at : main, etc.. This crash also seems to be dependent on the code being compiled in the main function.
Now, does this have any dependency on which compiler is used with the gdb server and arm-none-eabi-gdb.exe programs? For instance, if I compiled the code with Atollic versus Keil versus code sourcery versus IAR, would the Attollic gdb service + arm-none-eabi-gdb programs be able to work with any compiled code? Are there some missing symbols somewhere not being generated? For reference, I am using an EVAL version of the IAR compiler tool set. If I make a project with the same code in embedded workbench using the STLINK, the code compiles and debugs fine.
What is a CFA rule? Call frame address? Am I not setting up the stack pointer or something in my program? I thought the IAR compiler took care of all that junk in the cstartup.
Any help is appreciated.
Thanks,
LostTime77
I installed play 2.0 from the typesafe stack.
However, when i try to run sbt debug run it gives me the error:
[error] Not a valid key: debug (similar: idea)
Any suggestions on how to run a debug server?
In order to debug with the sbt command instead of the play command, you have the option to set the env. variable SBT_OPTS with the classical
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9999
Source : https://groups.google.com/forum/?hl=fr&fromgroups#!topic/play-framework/-RVlEh8S2F4
I spent quite some time on this tonight. Hope my experience helps.
And as many of you I am encountering same issue that debug is not recognized under sbt. The easiest way of course is to follow the documentation. install the Play standalone and run the play debug run command, and then debug remote java application using the 9999 port.
but #Julienlafont 's solution did workout as well (I had the confusion at first as well). The key is to understand the whole process. Play web server is still served through port 9000. but port 9999 is opened as debug port to let IDE connect to , this is important.
I guess the reason why debug is not recognized is because it is not a sub command at all. it is indeed a couple of JVM arguments as #Julienlafont point out. so the what play command did is simply wrap the JVM argument for you. note once you enter the play console, the debug extension wont be recognized, because its essence is a couple of JVM arguments.
so go ahead set that JVM argument, once you see the hint , you are done with opening the debug port. run your server and finish the remaining part.