NullPointerException in DefaultPersistentDirectoryStore when reading/writing from build cache #4216
Comments
adrian-baker
changed the title
|
@lptr Maybe you can take a look at this. |
|
Actually reviewing the exceptions, it looks like the same null pointer can be hit when reading from the cache as well: |
adrian-baker
changed the title
|
@adrian-baker Thank you for the report! I have a lot of questions for you: Do you see those exceptions every time you run a build? |
|
It's reasonably intermittent - the trigger seems to be making a change in one of the projects in an included composite build, which triggers the issue maybe 75% of the time.
I've possibly found something that might be causing it - for our build server build, we use an init script which explicitly calls https://docs.gradle.org/current/javadoc/org/gradle/StartParameter.html#setTaskNames to specify the build tasks (this is so we keep our build server config as simple as possible - Oddly, when we set the tasks this way, I can see some subsequent logging after the "BUILD SUCCESSFUL" message. I've attached two logs showing this, one without the null pointer, one with. If remove the task setting from the build script and specify the same tasks on the command line, I don't see the extra logging or null pointers. |
|
Ah, actually checking that log it's actually a different error ("Cannot lock Build cache (C:\Users\ABaker.gradle\caches\build-cache-1) as it has already been locked by this process."). Here's one with an actual null pointer - really-with-null-pointer.log |
|
I managed to reproduce the issue. It is related to us sharing the build cache configuration for composite builds starting with Gradle 4.5. |
|
You can avoid the problem if you add a task to your root build which depends on the tasks you want to execute in the composites. |
Sharing the service causes problems when they are shut down - sometimes the root service is shut down even if one of the included builds is still running and using it. #4216
Sharing the service causes problems when they are shut down - sometimes the root service is shut down even if one of the included builds is still running and using it. #4216
We only did this so that we are able to observe the cleanup build operations. This should be handled differently: cleanup operations from caches should be seen as build operations automatically. By removing the `buildFinished` listener #4216 is fixed.
|
@adrian-baker I fixed this via #4249. We are going to do a 4.5.1 release. Could you try out a release snapshot to see if the issue is fixed for you: 4.5.1-20180202223039+0000. |
|
Working well - thank you. |
We're seeing a number of NullPointerExceptions while populating the build cache.
We're using composite builds, so I can't attach a build scan.
This is using Gradle 4.5, with both org.gradle.parallel and org.gradle.configureondemand set to true.
I don't believe the errors are impacting the results of the build, however they are likely hurting the effectiveness of the cache.
The text was updated successfully, but these errors were encountered: