gradlew stuck at listening for transport dt_socket - gradle

On cmd, all gradle commands like "gradlew, gradlew -version, gradlew build" get stuck with one line
Listening for transport dt_socket at address:5006

Most probably, your Gradle runs in debug mode. Debug can be turned on in different ways. Check the value of GRADLE_OPTS environment variable and org.gradle.jvmargs Java system property. Latter can be set in different places: on the project level (in gradle.properties in project root) or in global config (~/.gradle/gradle.properties).
Setting suspend to n will allow you to both run the process in debug mode and do not wait for the debugger.

Related

When running a gradle unit test from command line, how can I get a debugger?

I'm running unit tests from the gradle command line (because running them from IntelliJ was causing problems for some reason.)
So I'd like to turn on a debug port for remote debugging from the unit test. How can I do that? Is there a way to send the -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y into the unit test itself? I'm using Gradle daemon mode so I'm not sure how that all works and can't find any documentation about it.
Actually it turned out that there's no need to set the jvmArgs manually. Instead you just need to invoke (docs):
gradle someTestTask --debug-jvm
and it will stop execution and wait for debugger connection. Now when this process hangs, go to IntelliJ, Eclipse (or other IDE) and set up an remote debugging configuration (remember to set source module - red arrow):
After it's set, run the debugger and you're done. Breakpoints may be set in IntelliJ directly.
Previous answer below:
test {
jvmArgs '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y'
}

Run application via gradlew with -Xmx and -Xms

I have an application. I run it via
gradlew run-app
Or debug
gradlew debug-app
It works. How do I pass '-Xmx' argument into the application which I run (debug)?
Is it possible to do so without edditing build.gradle file?
I found this
Gradle unknown command-line option '-X'
I get a similar error when I try
gradlew debug-app -Xmx2000m
Error
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :debug-app from command line.
> Unknown command-line option '-X'.
I tried to create a file gradle.properties in GRADLE_USER_HOME directory (by default, it is USER_HOME/.gradle).
org.gradle.jvmargs=-XX\:MaxHeapSize\=4256m -Xmx4256m -Xms2000m
I also tried to org.gradle.jvmargs=-Xmx2000m in project folder gradle.properties.
And even then when I run an application, I see Commited Memory size is < 520 MiB
And this is when I run it as a normal Java App
In the second case, when I run the application as a normal Java app with -Xms, -Xmx, Commited Memory size is about 3.5 GiB because I passed -Xmx4512m -Xms2512m parameters.
Add this in your gradle.properties file :
org.gradle.jvmargs=-Xmx2000m
From here
org.gradle.jvmargs
Specifies the jvmargs used for the daemon process. The setting is
particularly useful for tweaking memory settings. At the moment the
default settings are pretty generous with regards to memory.
edit : my answer what about the gradle daemon jvm, not the app jvm. You have to use the jvmArgs property
The extra arguments to use to launch the JVM for the process. Does not
include system properties and the minimum/maximum heap size.
Firstly, thanks #ToYonos for leading me to the right direction.
Secondly, I found the solution here https://stackoverflow.com/a/9648945/4587961.
I ran my app from command line.
set GRADLE_OPTS=-Xms1724m -Xmx5048m
gradlew debug-app
Note, CMD Windows command SET works locally, so if you close your terminal, GRADLE_OPTS will not be set. For Linux, you can use
export GRADLE_OPTS=WHATEVER
This is what I wanted to achieve.
Using application plugin one can use applicationDefaultJvmArgs property
apply plugin: 'application'
applicationDefaultJvmArgs = ["-Xms1024m", "-Xmx2048m"]
The arguments will be applied to run task and to start script of your application
more info
In my case Invalidate cache and restart the android studio(which is automatically restarted) then the error will be gone after restarting the android studio
then

How to debug a Gradle build.gradle file (in a debugger, with breakpoints)?

Is there a tool that will allow me to set breakpoints in a build.gradle file and step through tasks in a debugger?
Note: I believe that I'm asking a different question than similar stackoverflow questions about debugging Gradle plugins, where (presumably) the intent is to step through custom Groovy or Java plugin code located in a separate file. I want to set a breakpoint in a Gradle task in a simple build.gradle file, like...
task example {
println "I want to set a breakpoint here"
}
...so that when I run gradle example I can inspect the context in a debugger.
(For those who would point me to IntelliJ...although JetBrains' website advertises that they support debugging Gradle scripts in IDEA UI, AFAICT this is untrue, as this was reported broken in IDEA13 EAP and hasn't been fixed in IDEA14. See Debugging Gradle build files in Intellij / Android Studio )
Is there any debugging tool that allows me to set a breakpoint in a build.gradle file, or is there something about the Gradle DSL that makes it fundamentally impossible to set breakpoints in a task such as my example, above?
There is the easier way:
just add in your command line -Dorg.gradle.debug=true --no-daemon
For example:
gradle nameOfTask -Dorg.gradle.debug=true --no-daemon
Then you should start your IDE and run remote debugging with localhost port 5005, that all.
Gradle is waiting to you, because standard option server=y
org.gradle.debug
When set to true, Gradle will run the build with remote debugging enabled, listening on port 5005. Note that this is the equivalent of adding -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 to the JVM command line and will suspend the virtual machine until a debugger is attached.
Link to docs
IntelliJ 2018.2 added the ability to debug Gradle scripts in a similar fashion to how you might run/debug other projects. You can see the announcement in the release notes here.
Here is a screenshot of some of the documentation from 2018.2:
It does not yet support the kotlin-dsl (see gradle/kotlin-dsl/issues/39).
Personnaly I do this when I need to debug build scripts:
Inside you terminal do
export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
Then run your build
gradle clean install
Finally put some breakpoints and launch the remote debug configuration inside your IDE on the port 5005 and you’re good to go!
export GRADLE_OPTS does not work for me.
Try this:
1 Add remote debug config
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
2 add breakpoint in gradle
3 ./gradlew your task --stacktrace -Dorg.gradle.daemon=false -Dorg.gradle.debug=true
4 Attach debug in studio
click icon
Then the breakpoint stops !!
If console is not goiong, click this in debug pannel in studio.
After reading various answers here the following steps will help you debug build.gradle to being able to break and investigate variables inside any custom task. I am using Eclipse remote debugging facilities
Place this simple code where you want to break: try {throw new RuntimeException('Break');} catch (RuntimeException e) {}
As recommended start your task with gradle mytask -Dorg.gradle.debug=true --no-daemon in the command prompt (don't have to do it in Eclipse)
In Eclipse do Run -> Add Java Exception Breakpoint, choose RuntimeException and click "OK"
Again in Eclipse go to Run -> Debug Configurations -> Remote Java Application and create new configuration that listens on localhost:5005. Name it whatever you want. Select a project that contains build.gradle you are debugging. Click Apply and Debug
At this point the execution will start but will pause at the Exception-throwing line. And you can then start looking at your variables in the `Debug -> Variables" view, inspect the stacktrace, step through the code etc.
No magic, alas, you will not see anything highlighted in build.gradle but you can pretty much guess where you are at
Obviously on subsequent runs you don't need step 3 and in 4 you can reuse previously created configuration
If you want to use this in the multiple places simply create a method, use different type of exception and feel free to enhance this idea in any way possible
For example:
void halt() {
try {
throw new RuntimeException('Break');
} catch (RuntimeException e) {
print('Paused')
}
}
task iterateDeclaredDependencies {
doLast {
Object configs = configurations.all
halt();
print(configs)
}
}
I use
set JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8989"
then 2 gradle processes are listening :
Listening for transport dt_socket at address: 8989
Listening for transport dt_socket at address: 8989
I can connect to both of them with 2 remote debug launch configurations in Eclipse although it's the same port.

Launched gradle with a test with the --no-daemon parameter but the daemon is launched anyway

I'm trying to debug some unit tests I've written but the gradle daemon seems to always launch, ignoring any options I've set.
Using Mac OS X 10.9.5, Java 1.7, Gradle 2.2.1 and robolectric-gradle-plugin 0.14.1
Launching gradle with:
GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006"
./gradlew test --no-daemon -Dorg.gradle.debug=true
causes the following line to appear
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguid....
I've also tried setting the -Xdebug and Xrunjdwp as jvmArgs in build.gradle.
Nothing else happens but if I add -d and rerun, it turns out that the daemon has launched and is waiting on port 5005 for a debugger: http://pastebin.com/TqaXubmr
Finally, if I then launch a debugger attaching to port 5005 the tests run but none of the breakpoints are hit.
The gradle.properties is empty, I haven't set org.gradle.jvmargs.
You might have configure memory settings in your gradle.properties? these can force gradle to launch a new jvm as these settings cannot be applied dynamically.
Keep in mind that unit tests are always executed in a separate jvm. The easiest way to debug tests executed by gradle is to run
>gradle :test --debug-jvm
this will automatically configure your test task to run with debug enabled.

How to set system properties in IntelliJ IDEA 13 gradle task?

I have a Spring Boot project with gradle build tool. The JDBC url, username and password are kept in a property file which is not part of application it's a external property file, the path of the property file is taken from system properties as follows.
export _JAVA_OPTIONS=-DdatabaseConfiguration=db.properties
It is working if I run the application from terminal using gradle bootRun, but when I try to run from Intellij IDEA 13 gradle tasks its not working, the property value is null.
I tried the VM options in Run/Debug Configuration as in the below screen shoot its not working either
How can the JAVA_OPTIONS can be set in Intellij IDEA 13 gradle tasks.
This is because every time you use the Gradle tool window to kick off tasks in IntelliJ, it creates/overwrites the launch configuration for that task.
Basically, I've had to run from the Gradle tool window just once. Then I go into the failed Launch Config (shown in question) and enter the system property in the VM options. From there on out, I need to use that Launch Config to execute the task instead of the Gradle tool window.
Update: Even better solution:
Preferences->Build, Execution, Deployment->Build Tools->Gradle->Gradle VM options
Add your system properties there (i.e. -Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk)
Doing this will keep them from getting overwritten/lost in the Launch configs that the Gradle tool window generates.
Another thing to note is that using the Gradle tool window causes the commands to be run without access to Environment Variables. This can cause a lot of problems with builds that depend on these env vars.
I ran into this today with the appengine-gradle-plugin and had to put
-Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk
in the VM options because it was not seeing the env vars. From the command line, it picks up the env vars and works fine. This worked for my appengineRun task.
But it does not work for appengineUpdate since that gives another error caused by lack of env vars: Toolkit not found: apple.awt.CToolkit

Resources