Question

[Solved] Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) while building Android project on Jenkins

I have an Android Project that builds successfully on Android Studio.

Now I want to build it on Jenkins. But when I’m doing I got the following error:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Exception is:

org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
    at org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:222)
    at org.gradle.launcher.daemon.client.DaemonClient.monitorBuild(DaemonClient.java:198)
    at org.gradle.launcher.daemon.client.DaemonClient.executeBuild(DaemonClient.java:162)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:125)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:80)
    at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43)
    at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:241)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:214)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:207)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
    at org.gradle.launcher.Main.doAction(Main.java:33)
    at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:23)

I read related topics, but it does not help. I tried to build it using gradle daemon, and without it, but the problem still exists.

Solution #1:

EDIT Looks like there has been a few changes with the new versions of Gradle.

Since 3.0 you should not disable the daemon on your CI anymore

[We] recommend using [the daemon] for both developers’ machines and Continuous Integration servers.

However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.

PREVIOUS ANSWER

It’s recommended to turn off daemon on any CI server. use this option to disable it

--no-daemon
Respondent: Oleg Khalidov

Solution #2:

After getting this crash I tried several things to get the GradleDaemon to stop running on my CI server. None of which worked.

I found an answer on a gradle.org forum which suggested that the GradleDaemon would always run anyway. The –no-daemon flag would just make it run for this specific build rather than staying on indefinitely.

If you specify JVM arguments that require forking, Gradle will fork a new JVM. Regardless of whether or not you want a daemon process, the class that runs is called GradleDaemon. The –no-daemon switch should cause the forked process to be single use instead of a long running daemon process, but it’s still going to run the GradleDaemon class.

Source: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5

I may be reading this wrong and I can’t vouch for the validity of the answer, but I think the cause of this error is just a lack of memory for Gradle. As it is always going to run the GradleDaemon.

So I added

org.gradle.jvmargs=-Xmx1024m 

to my ~/.gradle/gradle.properties file and it no longer gave me that error.

Respondent: MungoRae

Solution #3:

It seems like it is a memory related issue. Nevertheless, disabling the daemon as suggested by Oleg does seem to help.

Use

org.gradle.daemon=false

in

gradle.properties

either in ~/.gradle folder or the project’s folder.

Ref: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

Respondent: muthusuba

Solution #4:

In our case the issue was caused by the CI server passing environment variables with non-ascii characters (i.e. in the names of commit authors).

Adding file.encoding=utf-8 to Gradle properties fixed the issue immediately.

Respondent: akru

Solution #5:

gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

Or add org.gradle.jvmargs=-Xmx1536m to gradle.properties file.

Respondent: HellenGo

Solution #6:

No one else may run into this, as it’s quite silly, but…

My issue was a strange character being present in my commit message…I had copied a previous commit message from gitlab which contained an emoji and pasted that into the title of a merge request, instead of the normal :bug: syntax.

akru’s answer helped point me in the right direction ?

Respondent: jacoballenwood

Solution #7:

Gradle build daemon disappeared unexpectedly in many cases mean gradle itself or even java crashed.
In my case it was java. Fill bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1408857

Look at files named like: hs_err_pid%p.log where %p is PID of process in directory from what you are run gradle task.

Update: It looks like gradle itself issue. In my case because of use native jansi. In issue provided workaround:

ln -sb /dev/null /home/pasha/.gradle/native/jansi/1.17.1/linux64/libjansi.so
Respondent: Hubbitus

Solution #8:

Wow, in my case closing the Android Studio and re-opening it worked just fine and the error was gone. 🙂

Respondent: Rahee

Solution #9:

I have tried the --no-daemon solution but my build continued to fail with the same DaemonDisappearedException.

I solved this by increasing the RAM of the server I am running Jenkins upon. In AWS EC2 that meant having to increase the EC2 instance type which results to an increase RAM.

Respondent: Mark Pazon

Solution #10:

Sometimes just doing Build -> Clean Project works – Give that a try before you start with the other gradle file changes.

Respondent: shellym

Solution #11:

I had the same issue, in the end there was a missing argument in the gradle file

Basically, this was a kotlin project, in which some experimental coroutine features were used. The class which used it was marked with

@OptIn(FlowPreview::class) 

This requires adding the following argument in the build.gradle, although it was running just fine in android studio locally

kotlinOptions {
        jvmTarget = "1.8"
        freeCompilerArgs = [ "-Xopt-in=kotlin.RequiresOptIn"]
    }

Spent a lot of time looking for this one

Respondent: Cyber Gh

Solution #12:

Most of the time you only need to restart Android Studio and it should work. Also you can do the following: File -> Sync Project with Gradle Files and then File -> Invalides Cachse / Restart.

Respondent: Rawand Saeed

Solution #13:

I was using Android Studio in Windows 7 and then this error appeared. What worked for me is killing Java.exe from Windows TaskManager.

Respondent: SrikanthS

Solution #14:

In my case, I was upgrading my android studio project and I use ZelixKlassMaster for obfuscating my code the issue wa that, I had my class-path on Zelix set to 27 but my project was using android 28 Hope this will help any future comers the way I debugged this was my seed file was printing out this error

ERROR: Invalid classpath in "classpath" statement at line 69 : "C:UsersRabAppDataLocalAndroidSdkplatformsandroid-27android.jar" is not a valid path.
Respondent: SamHoque

Solution #15:

Before assemble task.

./gradlew --status

check daemon status.

Then

./gradlew --stop

to stop the daemon.

Use

./gradlew assemblerelease  --no-daemon -Dkotlin.compiler.execution.strategy="in-process"

to disable daemon.

Respondent: TerrenceZhang

Solution #16:

Add in gradle.properties file.

org.gradle.daemon=true <br>
org.gradle.jvmargs=-Xmx1024m <br>
android.useDeprecatedNdk=true <br>
android.useAndroidX=true <br>
android.enableJetifier=true <br>
file.encoding=utf-8
Respondent: user2991182

Solution #17:

i had the same issue added these in the gradle.properties file

android.useAndroidX=true
android.enableJetifier=true
org.gradle.jvmargs = -Xmx2g
Respondent: Bakhtawer Jabeen

Solution #18:

Go to /gradle.properties then remove org.gradle.jvmargs=-Xmx1024m and if org.gradle.jvmargs=-Xmx1024m not available then Add this code in your /gradle.properties.

Respondent: Arjun Yadav

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Most Popular

To Top
India and Pakistan’s steroid-soaked rhetoric over Kashmir will come back to haunt them both clenbuterol australia bossier man pleads guilty for leadership role in anabolic steriod distribution conspiracy