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

Question

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.

Answer 1

if you are facing this issue with Gradle 8.8 macOS, those maybe something in Gradle side, you can simply add org.gradle.vfs.watch=false to gradle.properties to fix.

Refer: Gradle 8.8 crashed on macOS File System Watching

Answer 2

I tried all solutions but no luck. I made a small change in my GitHub action workflow - stopped the gradle process and started again. After that, everything was good to go.

Am not getting the error of

"Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)"

My workflow code:

  - name: Execute the flank command and run instrumentation tests.
    run: |
      ./gradlew --status
      ./gradlew --stop
      ./gradlew runFlank

Answer 3

In our case what fixed the error is updating build-tools version.

Target SDK in our case is 33 and we use build-tools for Arxan SDK.

There was a line on .yml file which uses build-tools v.29.0.0.

Updating that one to 33.0.2 fixed this issue.

In our case we use Github Actions which runs-on: ubuntu-latest-8-cores

And our gradle.properties jvmargs is:

org.gradle.jvmargs=-Xmx3g -Xms2g -Dfile.encoding=UTF-8 -XX:+CMSClassUnloadingEnabled -XX:MaxMetaspaceSize=1g -XX:+HeapDumpOnOutOfMemoryError

Answer 4

The problem still persists on different CIs. We running our routines on GitHub Actions on Linux build agents.

I decided to profile our build locally using Visual VM. I found out that each build spins up 2 daemons: 1 for gradle and 1 for kotlin compiler. Try limiting the memory for kotlin compiler. We are using this memory flags for gradle in gradle.properties:

# Dkotlin.daemon.jvm.options specifies memory limits for kotlin compiler
org.gradle.jvmargs=-Xmx4G -Dkotlin.daemon.jvm.options=-Xmx2G -XX:+HeapDumpOnOutOfMemoryError -XX:+UseParallelGC -Dfile.encoding=UTF-8

You must find a balance between gradle daemon heap and kotlin compiler daemon heap. gradle + kotlin < 7GB or else Linux will kill gradle daemon. It is important to leave some RAM for Linux or else it'll kill gradle daemon.

If you give not enough heap to gradle/kotlin daemons build will fail with OurOfMemoryError. Different technologies and projects may require different heap sizes for gradle and compiler. Unit tests/UI tests require additional kotlin daemon. Our project is relatively big and memory-hungry so we are only able to build artifacts with configs I showed above.

So in some cases default build agents may be insufficient for your project. In that case consider paying for stronger agents or setup local build machine in your office to cover your needs.

Answer 5

Take my experience as an example, check and increase the swap space if needed, if you are running Linux OS.

It is recommended to have swap size as large as the ram size.

1. First, find the swap file, disable and delete it

   swapon --show
   NAME      TYPE SIZE USED PRIO
   /swapfile file   2G   0B   -2
   
   sudo swapoff /swapfile
   sudo rm  /swapfile
   

2. Create new swap space of size 16 GB (16 * 1024 = 16384). bs is the block size. Basically bs * count = bytes to be allocated (in this case 16 GB). Here bs = 1M (M stands for mega, so we are assigning 1MB block size) and we are allocating 16384 * 1MB (=16GB) to swap.

   sudo dd if=/dev/zero of=/swapfile bs=1M count=16384
   

3. Give it the read/write permission for root

   sudo chmod 600 /swapfile
   

4. Format it to swap

   sudo mkswap /swapfile
   

5. Turn on swap again

   sudo swapon /swapfile
   

6. Now reboot the PC for the above changes to take place.

Refer: https://askubuntu.com/a/1264577

Answer 6

It is a combination of number of parellel demons are running and how much heap space you are utlising. so check how much heap is avaliable and create a configuration accordingly

-Xms256m -Xmx1024m

Number of forks = number of parallel test cases are exectuing

tasks.test { maxParallelForks=2 }

so ideally you can expect minimum 2 parallel demon is running with

max = 2* 1024 memory.

NOTE: if you have more demon running and you keep on increase heap space. that also cause out of memory

So try to find an optimal count for Fork (number of parallel demons)
and heap space for it

Answer 7

It appears this type of problem (Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)) is becoming more common as people move to GitHub workflows and GitHub Actions.

We never saw this problem when building locally (command line or Android Studio), or when building on our Jenkins build server. But as soon as we started testing builds through GitHub Workflows/Actions this type of build error would happen intermittently.

Every project is different, so it appears there are several solutions that may work. After a lot of experimenting with our builds, the only parameter that reliably fixed this problem was '-XX:MaxMetaspaceSize'.

GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

No changes to build.gradle, gradle.properties, gradle-wrapper.properties, etc. were needed in our case. Just the single GRADLE_OPTS line in our GitHub workflow yaml. This explanation from the Java docs was the most helpful (avoiding unbounded growth of class metadata space).

In previous releases of Java Hotspot VM, the class metadata was allocated in the so-called permanent generation. Starting with JDK 8, the permanent generation was removed and the class metadata is allocated in native memory. The amount of native memory that can be used for class metadata is by default unlimited. Use the option -XX:MaxMetaspaceSize to put an upper limit on the amount of native memory used for class metadata.

Source: https://docs.oracle.com/en/java/javase/17/gctuning/other-considerations.html

Working example of GitHub Workflow:

jobs:
  build:

    runs-on: ubuntu-latest

    env:
      GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

    steps:
    - uses: actions/checkout@v2
      with:
        ref: 'master'
        fetch-depth: 0

    - name: Set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Gradle Build
      uses: gradle/gradle-build-action@v2
      with:
        arguments: build -x lint appDistributionUploadRelease

Answer 8

This is how it worked for me:

Enable the gradle deamon (this is the default with gradle 7).

org.gradle.daemon=false

Install Jenkins Plugin: https://plugins.jenkins.io/gradle-daemon/

The Plugin will prevent to kill the deamon if another build is still using it.

Answer 9

I got the same error in Docker, and I tried to set org.gradle.daemon=false and all the above ways, but it didn't work . At last, I update the gradle to version 6.5 and the android gradle plugin to version 4.1.0. then the error disappeared.

Answer 10

In my case, removing org.gradle.parallel=true did the trick.

My gradle.properties for your reference:

org.gradle.daemon=false
org.gradle.jvmargs=-Xmx3g -XX:MaxMetaspaceSize=768m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
kotlin.compiler.execution.strategy=in-process

PS: I'm using this configuration for running Android Workflows with GitHub Actions (ubuntu-20.04)

Answer 11

I was experiencing the same issue in GitHub Actions. As other answers mention, it seemed to be a memory issue.

The following settings worked nicely for me with the GitHub Ubuntu runner (no need to disable the deamon):

# ...
env:
  GRADLE_OPTS: -Dkotlin.incremental=false -Dorg.gradle.jvmargs="-Xmx4g -XX:MaxMetaspaceSize=2g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # ...
      - name: Build app
        run: ./gradlew assembleRelease --stacktrace

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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

Answer 17

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:\Users\Rab\AppData\Local\Android\Sdk\platforms\android-27\android.jar" is not a valid path.

Answer 18

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 🙏

Answer 19

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

Answer 20

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

Answer 21

gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

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

Answer 22

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

Answer 23

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.

Answer 24

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.

Answer 25

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.