[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: |
|
Description |
Since Gradle 1.12, in some environments PosixFileFunctions.chmod is failing with an UnsatisfiedLinkError: Build time: 2015-02-10 23:00:25 UTC Groovy: 2.3.9 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 gradlew clean build --stacktrace 17:20:04 :clean |
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:
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. |