Exception: Problems reading data from Binary store

[ghilainm]

I have an exception while running gradle dependencies.

* What went wrong:
Execution failed for task ':dependencies'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
   > Problems reading data from Binary store in /tmp/gradle15981587407420935578.bin offset 525 exists? true

Here are the characteristics of my project:

• Java project using java-library plugin
• Tried with Gradle 6.4.1 / 6.5-rc-1 / 6.5
• Using dependency locking
• Simple project (no multi-project, no composite build)
• Using Spring platform
• Using custom plugin which adds configuration
• Using several repositories
• Using latest.release
• No using the wrapper

I have tried to:

• Delete completely my grade directory (caches/wrapper/...)
• With and without dependency locking
• Run command gradle clean dependencies --no-parallel --no-build-cache -> same error

However, running the task gradle compileJava works.

Any idea what I could try more?

[mmoayyed]

I have run into the same problem.

Running:

• JDK 11.0.7
• Gradle 6.5 (Also seeing issues with 6.4.1 and 6.4)
• MacOS Catalina

To reproduce:

git clone --depth 1 git@github.com:mmoayyed/cas.git
cd cas/support/cas-server-support-ignite-ticket-registry
../../gradlew dependencies


Problems reading data from Binary store in 
/private/var/folders/wf/rcc_265x1ld1n8jh47bgmbqm0000gn/T/gradle986346894448844168.bin offset 7361 exists? true

So far,

• Removed the local .gradle folder; No difference
• Removed the home .gradle folder; No difference
• Ran the command, having disabled parallel, config-on-demand and daemon; No difference
• Tried on a brand new Windows 10 machine; No difference
• With or without wrapper; No difference

Update v1

• Just to make sure this is not related to a local corrupt cache, etc, I was also able to see this failure while having SSHed into a build environment backed by Github Actions. Same issue popped up there. Another observation is that the issue seems specific to the compileClasspath configuration; others seem to do OK.

[ghilainm]

I have got exactly the same issue in another context. I could boil it down to one dependency causing the issue, but don't know why this dependency is causing the issue... if you wanna do remote debug I am available.

I did play around with that dependency and changing it's configuration from implementation to runtimeOnly fixes the issue (but that's not what I want obviously) and changing from latest.release to a fixed version (tried several versions) didn't change anything.

[ljacomet]

Thanks for the report and the reproducer.

While I can't say for sure that the issue in the reproducer is the exact same one as the original report, it allowed to track a real issue.

Because of the usage of excludes, the graph building ends up recomputing a large number of constraints. One of those is the sole version specifier for org.glassfish:jakarta.el, as the real dependency edge is without version. And the graph building contains a bug that results in disconnected node.

Validating a fix and then I will be able to share a custom build for you to validate.

[ljacomet]

We have published a custom version to allow you to confirm the fix works.

Could you test it?
@mmoayyed I have tested it on your reproducer and the problem is fixed.

@ghilainm Given the root cause, it is quite likely this fixes the issue for you as well as Spring Boot projects are particularly sensitive to this bug.

Testing can be done by updating the wrapper:

./gradlew wrapper --gradle-version=6.6-branch-ljacomet_dependency_management_graph_invalid-20200605145923+0000

[mmoayyed]

@ljacomet Appreciate the update. I will provide an update shortly. Thanks much for the help!

[mmoayyed]

@ljacomet I can confirm that the issue is fixed/gone. Thanks very much!

[burhanudinnuban]

in android/build.gradlew :
firebaseMessagingVersion = "+" change to firebaseMessagingVersion="21.1.0"
this solved and worked for me

[mannnish]

We have published a custom version to allow you to confirm the fix works.

Could you test it?
@mmoayyed I have tested it on your reproducer and the problem is fixed.

@ghilainm Given the root cause, it is quite likely this fixes the issue for you as well as Spring Boot projects are particularly sensitive to this bug.

Testing can be done by updating the wrapper:

./gradlew wrapper --gradle-version=6.6-branch-ljacomet_dependency_management_graph_invalid-20200605145923+0000

getting this error

Downloading https://services.gradle.org/distributions-snapshots/gradle-6.6-branch-ljacomet_dependency_management_graph_invalid-20200605145923+0000-bin.zip

Exception in thread "main" java.io.FileNotFoundException: https://downloads.gradle-dn.com/distributions-snapshots/gradle-6.6-branch-ljacomet_dependency_management_graph_invalid-20200605145923+0000-bin.zip
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1890)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at org.gradle.wrapper.Download.downloadInternal(Download.java:67)
at org.gradle.wrapper.Download.download(Download.java:52)
at org.gradle.wrapper.Install$1.call(Install.java:62)
at org.gradle.wrapper.Install$1.call(Install.java:48)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
at org.gradle.wrapper.Install.createDist(Install.java:48)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:63)