[GRADLE-2041] circular task dependency to 'self' is hard to diagnose Created: 11/Jan/12 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Gradle Forums | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 1 |
Description |
Comments |
Comment by Gradle Forums [ 11/Jan/12 ] |
Hey Stefan, It looks like the problem occurs regardless of the tasks you run. Can you confirm? |
Comment by Gradle Forums [ 11/Jan/12 ] |
Yes, actually running gradle tasks gives me a java.util.ConcurrentModificationException: 08:34:15.504 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] task ':tasks' is not up-to-date The other tasks I tried are:
|
Comment by Gradle Forums [ 11/Jan/12 ] |
I can add that milestone-6 has exactly the same issues. |
Comment by Gradle Forums [ 11/Jan/12 ] |
Can you provide a build that allows us to reproduce the problem(s)? |
Comment by Gradle Forums [ 11/Jan/12 ] |
Sure, I'll see what I can do. |
Comment by Gradle Forums [ 11/Jan/12 ] |
Um, I'm not exactly sure what's the easiest way to do this, however through using the debugger I have managed to find the case where the "tasks" task breaks: 1. Inside GraphAggregator.java there is this method: public Result<N> group(Collection<? extends N> startNodes, Collection<? extends N> allNodes) { The ConcurrentModificationException is thrown on one of the topLevelNodes.removeAll(reachableNodes); calls (Note: since gradle is single threaded, so the only way this exception would be thrown is by modifying some iterator while we are iterating). 2. Let me setup all the variables which lead to the exception being thrown: 3. We can assume that the for loop iterates over the allNodes in the sequence provided. 4. Skipping ahead to the point where the N node = task ':databus-bootstrap-client:databus-bootstrap-client-impl:cobertura' we have the following reachableNodes = [task ':databus-bootstrap-client:databus-bootstrap-client-impl:instrumentedJar', task ':databus-bootstrap-client:databus-bootstrap-client-impl:coberturaXml', task ':databus-bootstrap-client:databus-bootstrap-client-impl:cleanTest', task ':databus-bootstrap-client:databus-bootstrap-client-impl:test', task ':databus-bootstrap-client:databus-bootstrap-client-impl:testClasses', task ':databus-bootstrap-client:databus-bootstrap-client-impl:classes', task ':databus-bootstrap-client:databus-bootstrap-client-impl:processTestResources', task ':databus-bootstrap-client:databus-bootstrap-client-impl:compileTestJava', task ':databus-bootstrap-client:databus-bootstrap-client-impl:compileJava', task ':databus-bootstrap-client:databus-bootstrap-client-impl:processResources'] 5. So examining the *reachableNodes, **topLevelNodes* & *allNodes* variables, we see that the next value of *N node* would be :databus-bootstrap-client:databus-bootstrap-client-impl:coberturaXml. But it is also in *reachableNodes* and *topLevelNodes. So when we come to do a **removeAll* on *topLevelNodes, we expect *:databus-bootstrap-client:databus-bootstrap-client-impl:coberturaXml to be removed. However the way *topLevelNodes* is initialized, it causes some deeper iterator interference which modifies the iterator being used for the for loop and *thus the exception* . 6. Please advise. |
Comment by Gradle Forums [ 11/Jan/12 ] |
Thanks for the detailed analysis. It will certainly help us in our investigation. |
Comment by Gradle Forums [ 11/Jan/12 ] |
One minor correction: the exception is thrown by the for loop when it does to get the next item, not in the removeAll step. i.e. after the removeAll step and we go to the next iteration of the forloop (which does a iterator.next() call). |
Comment by Gradle Forums [ 11/Jan/12 ] |
Hey Stefan, By reading the code I cannot figure out how come that exception can be thrown. topLevelNodes, reachableNodes can contain the same item and we still should be able to removeAll() without interfering. Do you have that dev environment still set up? Can we pair on it remotely? If we cannot than I suggest to dig a bit into what is changed in the allNodes and when (e.g. eager breakpoint at all mutators or some more code analysis) |
Comment by Gradle Forums [ 11/Jan/12 ] |
The issue has been solved by removing the circular dependency. However, the problem with awkward reporting still persists, e.g. "Cycle includes [task '::cmdline', task '::cmdline']". I'll push that to jira. |
Comment by Gradle Forums [ 11/Jan/12 ] |
Well it's the next thing that the for loop iterator would go over, and it's just been removed... But yeah I havent had a chance to debug it with the fix to see what's changed. |
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. |