[GRADLE-917] ConcurrentModificationException in DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:51) Created: 21/Apr/10  Updated: 07/May/13  Resolved: 07/May/13

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: None

Type: Bug
Reporter: Philip Crotwell Assignee: Unassigned
Resolution: Duplicate Votes: 2

Issue Links:
Duplicate
Duplicates GRADLE-2512 Provide a better error message when t... Resolved

 Description   

Have this task in my build.gradle to deal with some relaxng:

task buildSchema(dependsOn: classes) << { task ->
inputs.dir 'src/main/relax/'
outputs.files 'src/main/resources/edu/sc/seis/sod/data/sod.rng'
doLast

{ outDir = task.project.file('build/output') outDir.mkdirs() relaxArgs = project.projectDir.path+'/src/main/relax/sod.rng' ant.java(dir:outDir, classname:'com.sun.msv.writer.relaxng.Driver', args:relaxArgs, maxmemory:'512m', fork:true, classpath:configurations.runtime.asPath, output:task.project.projectDir.path+'/src/main/resources/edu/sc/seis/sod/data/sod.rng') }

}

I made a small change (the inputs/outputs/doLast) to take advantage of the new Incremental build stuff in gradle 0.9 but got this:
<snip>
:sod:classes UP-TO-DATE
:sod:buildSchema

FAILURE: Build aborted because of an internal error.

  • What went wrong:
    Build aborted because of an unexpected internal error. Please file an issue at: www.gradle.org.
  • Try:
    Run with -d option to get additional debug info.
  • Exception is:
    java.util.ConcurrentModificationException: null
    at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
    at java.util.AbstractList$Itr.next(AbstractList.java:343)
    at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:51)
    at org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:41)
    at org.gradle.api.internal.project.taskfactory.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:32)
    at org.gradle.api.internal.project.taskfactory.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:48)
    at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:57)
    at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:35)
    at org.gradle.api.internal.tasks.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:32)
    at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:224)
    at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:165)
    at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:158)
    at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:77)
    at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:161)
    at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54)
    at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:177)
    at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
    at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:80)
    at org.gradle.launcher.Main.execute(Main.java:93)
    at org.gradle.launcher.Main.main(Main.java:42)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:54)

BUILD FAILED

It seems to be reproducable, (three times in a row at least).

 Comments   
Comment by Philip Crotwell [ 21/Apr/10 ]

Found that if I change the first line to:
task buildSchema(dependsOn: classes) { task ->
(ie no <<) then it works fine.

Comment by Spencer Allain [ 11/Aug/10 ]

task someName << { doLast { } }
task someOtherName << { doFirst { } }
task someThirdName { doFirst { doLast { } } }
Any of these are sufficient to cause the exception every time.

Comment by Leonard Brünings [ 27/Apr/11 ]

That is because
task someName <<

{ ... }
is just a shorthand for doLast {}

You can't modify the tasks while executing the task itself,
so not really a bug but maybe a better Error Message might help.

Also your code won't work as expected if you use
task someName << { ... }

since inputs and outputs need to be configured during the configuration phase,
but with this you only configure it when you are already executing. So when
gradle checks if your task is out of date it will not see your config.

Generated at Wed Jun 30 11:42:15 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.