Daemon fails with "ERROR: transport error 202: bind failed: Address already in use" error if run from different version of Gradle or JDK

Old Forum
1

When switching versions of Gradle or JDKs, running gradle will result with the daemon failing to start with the message:

FAILURE: Build failed with an exception.

  • What went wrong: Unable to start the daemon process. This problem might be caused by incorrect configuration of the daemon. For example, an unrecognized jvm option is used. Please refer to the user guide chapter on the daemon at http://gradle.org/docs/current/userguide/gradle_daemon.html Please read below process output to find out more: ----------------------- ERROR: transport error 202: bind failed: Address already in use ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized […/…/…/src/share/back/debugInit.c:741] FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)

Different projects use different versions of Gradle and/or JVMs, so this gets annoying. Many of our developers don’t use the daemon for this reason, and that slows things down.

Gradle should be able to kill older daemons if they’re not the right version instead of erroring out.

2

Can you provide more information, like your OS, gradle.properties, stack trace, ways to reproduce, etc.? I constantly use different Gradle and JDK versions, and I’ve never encountered this error. Gradle does make sure to start new daemons when needed, and they do go away after some idle time (although there is certainly room to improve this).

3

Are you running daemons in debug mode? E.g. configured via jvm opts with connectable debug port and -Xdebug, etc.

4

I think that was it. We had our vm args set like so:

org.gradle.jvmargs= -Xms128m -Xmx768m -XX:MaxPermSize=256m -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

in the build script. I’ve commented out the debug stuff, and now it works.

Apparently, someone had set this so they could debug some code in Tomcat (via the Tomcat plugin, as that’s how they say to do it on their web page), and they placed this in the build script and never removed it.

It’d be nice to have the Tomcat plugin be able to take it’s own JVM args rather than telling users to do this via the GRADLE_OPTS route. They do mention an alternative is to just call Gradle with the JVM args on the command line, I’ll suggest that rather than putting it into the build script the way it was before.

Thanks for the help!

1 Like