[GRADLE-3241] PosixFileFunctions.chmod fails with UnsatisfiedLinkError in some environments for Gradle 1.12+ Created: 11/Feb/15  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.12, 2.0, 2.1, 2.2.1
Fix Version/s: None

Type: Bug
Reporter: Gary Hale Assignee: Gary Hale
Resolution: Won't Fix Votes: 2

Issue Links:
Related
Related to GRADLE-3076 Gradle 1.12-rc-2 fails with Unsatisfi... Resolved

 Description   

Since Gradle 1.12, in some environments PosixFileFunctions.chmod is failing with an UnsatisfiedLinkError:

Build time: 2015-02-10 23:00:25 UTC
Build number: none
Revision: 586be72bf6e3df1ee7676d1f2a3afd9157341274

Groovy: 2.3.9
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.8.020 (Oracle Corporation 25.20-b23)
OS: Linux 2.6.32-504.8.1.el6.x8664 i386

gradle clean build --stacktrace

FAILURE: Build failed with an exception.

What went wrong: net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Ljava/lang/String;ILnet/rubygrapefruit/platform/internal/FunctionResult;)V

Try: Run with --info or --debug option to get more log output.

Exception is: java.lang.UnsatisfiedLinkError: net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Ljava/lang/String;ILnet/rubygrapefruit/platform/internal/FunctionResult;)V at net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Native Method) at net.rubygrapefruit.platform.internal.DefaultPosixFiles.setMode(DefaultPosixFiles.java:39) at org.gradle.internal.nativeintegration.filesystem.services.NativePlatformBackedChmod.chmod(NativePlatformBackedChmod.java:32) at org.gradle.internal.nativeintegration.filesystem.services.GenericFileSystem.chmod(GenericFileSystem.java:69) at org.gradle.api.internal.file.AbstractFileTreeElement.copyTo(AbstractFileTreeElement.java:76) at org.gradle.api.internal.file.collections.MapFileTree$FileVisitDetailsImpl.getFile(MapFileTree.java:144) at org.gradle.api.internal.file.AbstractFileTree$1.visitFile(AbstractFileTree.java:39) at org.gradle.api.internal.file.AbstractFileTree$FilteredFileTree$1.visitFile(AbstractFileTree.java:145) at org.gradle.api.internal.file.collections.MapFileTree$Visit.visit(MapFileTree.java:113) at org.gradle.api.internal.file.collections.MapFileTree.visit(MapFileTree.java:75) at org.gradle.api.internal.file.collections.FileTreeAdapter.visit(FileTreeAdapter.java:96) at org.gradle.api.internal.file.AbstractFileTree$FilteredFileTree.visit(AbstractFileTree.java:136) at org.gradle.api.internal.file.AbstractFileTree.getFiles(AbstractFileTree.java:37) at org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileCollection.java:39) at org.gradle.api.internal.changedetection.state.DefaultFileCollectionSnapshotter.snapshot(DefaultFileCollectionSnapshotter.java:47) at org.gradle.api.internal.changedetection.rules.TaskUpToDateState.(TaskUpToDateState.java:55) at org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.getStates(DefaultTaskArtifactStateRepository.java:126) at org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:69) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:306) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62) at org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23) at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80) at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33) at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:169) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210) 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:206) 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 org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35) at org.gradle.launcher.GradleMain.main(GradleMain.java:23)

BUILD FAILED



 Comments   
Comment by François Guillot [ 16/Feb/15 ]

Well, I still get the error with gradle 2.3 at work (was OK until 1.11 included)

java.home /local3/atgl/product/java/jdk-1.6.0_16/linux-redhat/jdk1.6.0_16/jre
java.io.tmpdir /tmp
java.runtime.name Java(TM) SE Runtime Environment
java.runtime.version 1.6.0_16-b01
java.version 1.6.0_16
java.vm.version 14.2-b01
jna.platform.library.path /usr/lib:/lib
os.arch i386
os.name Linux
os.version 2.6.9-89.0.11.ELsmp

gradlew clean build --stacktrace

17:20:04 :clean
17:20:12 :compileJava
17:20:12 :processResources UP-TO-DATE
17:20:12 :classes
17:20:12 :jar
17:20:12 FAILURE: Build failed with an exception.
17:20:12
17:20:12 * What went wrong:
17:20:12 net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Ljava/lang/String;ILnet/rubygrapefruit/platform/internal/FunctionResult;)V
17:20:12
17:20:12 * Try:
17:20:12 Run with --info or --debug option to get more log output.
17:20:12
17:20:12 * Exception is:
17:20:12 java.lang.UnsatisfiedLinkError: net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Ljava/lang/String;ILnet/rubygrapefruit/platform/internal/FunctionResult;)V
17:20:12 at net.rubygrapefruit.platform.internal.jni.PosixFileFunctions.chmod(Native Method)
17:20:12 at net.rubygrapefruit.platform.internal.DefaultPosixFiles.setMode(DefaultPosixFiles.java:39)
17:20:12 at org.gradle.internal.nativeintegration.filesystem.services.NativePlatformBackedChmod.chmod(NativePlatformBackedChmod.java:32)
17:20:12 at org.gradle.internal.nativeintegration.filesystem.services.GenericFileSystem.chmod(GenericFileSystem.java:69)

Comment by Liguoqing [ 31/Mar/15 ]

I have the same error on Linux with NIGHTLY BUILD Veriosn 2.4-20150330220038+0000.

Comment by Gary Hale [ 13/Apr/15 ]

I've never been able to reproduce this behavior, but we've recently made some changes that likely have an effect on this. It would be great if someone could give this a try with the latest nightly and see if the issue still exists.

Comment by Jonathan Aguin [ 29/Apr/15 ]

I have tested this using the latest version of Gradle, gradle-2.5-20150428220042, and it is working fine. Does anybody know the actual cause of this problem?

Comment by Gary Hale [ 29/Apr/15 ]

Glad to hear it. You might also try this with 2.4-rc-2, which has the afore-mentioned changes.

I was never able to accurately reproduce the problem, so this is pure speculation, but if I had to guess, I would say that what was happening is that in the failing scenario, something was causing the Native libraries to be loaded twice from different locations (causing the UnsatisfiedLinkError). This was likely because of different classloaders coming into play, and these classes not being initialized properly, so the normal guard against this was not preventing the second load. We made a number of changes to how this stuff works, most prominently that 1) we ensure that these classes are always initialized properly before use and 2) that we centralize use of these classes in a single place. This may have fixed the problem because we effectively ensure that we only try to load the library once. That's just my best guess though.

Comment by Jonathan Neufeld [ 09/Feb/16 ]

I found that in one scenario this was caused by gradle attempting to write to files on a read-only file-system.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:43:40 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.