[
https://issues.apache.org/jira/browse/MNG-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7213:
-----------------------------------
Assignee: Tamas Cservenak
> StackOverflowError when version ranges are unsolvable and graph contains a
> cycle
> --------------------------------------------------------------------------------
>
> Key: MNG-7213
> URL: https://issues.apache.org/jira/browse/MNG-7213
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.6.3, 3.8.1
> Reporter: Henrik Rueping
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 3.9.1
>
> Attachments: babelcoreresolver.zip, babelcoreresolver15.zip
>
>
> I encountered a very similar situation as described in MNG-6737.
> It happens when I want to find the transitive dependencies of the Artifact
> org.webjars.npm:babel-core:6.0.16
> I tried the Maven-goal dependency:tree on a Maven-Project with only this
> Artifact in the pom.
> With Maven 3.6.3 I got a StackOverflowError (with a similar Stacktrace as
> below. The accept get repeated).
> With Maven 3.8.1 it took considerably longer and ended in an OutOfMemoryError
> (same Stacktrace).
> The same behaviour happens of course if I want to view the transitive
> dependencies of my
> project in Eclipse.
> I also tried to calculate the transitive dependencies in java itself, and I
> found that the Threads are stuck in a stacktrace of the form:
>
> {code:java}
> Thread [main] (Suspended) Stack<E>.get(int) line: 75
> AbstractList$Itr.next() line: 358
> Stack<E>(AbstractCollection<E>).contains(Object) line: 106
> PathRecordingDependencyVisitor.visitEnter(DependencyNode) line: 99
> DefaultDependencyNode.accept(DependencyVisitor) line: 343
> DefaultDependencyNode.accept(DependencyVisitor) line: 347
>
> (... omitted many Repititions...)
> DefaultDependencyNode.accept(DependencyVisitor) line: 347
> NearestVersionSelector.newFailure(ConflictResolver$ConflictContext) line: 158
> NearestVersionSelector.backtrack(NearestVersionSelector$ConflictGroup,
> ConflictResolver$ConflictContext) line: 120
> NearestVersionSelector.selectVersion(ConflictResolver$ConflictContext) line:
> 93 ConflictResolver.transformGraph(DependencyNode,
> DependencyGraphTransformationContext) line: 180
> ChainedDependencyGraphTransformer.transformGraph(DependencyNode,
> DependencyGraphTransformationContext) line: 80
> DefaultDependencyCollector.collectDependencies(RepositorySystemSession,
> CollectRequest) line: 273
> DefaultRepositorySystem.collectDependencies(RepositorySystemSession,
> CollectRequest) line: 284
>
> (..ommitted own code...)
> {code}
> I used:
> org.apache.maven:maven-resolver-provider:3.8.1
> org.apache.maven.resolver:maven-resolver-util:1.6.2
> I used ArtifactDescriptorPolicy.STRICT (maybe this setting makes a
> difference).
> So maybe it is not even a Bug, and it just happens that
> org.webjars.npm:babel-core:6.0.16 behaves a bit like a Zip-Bomb for Maven and
> there is nothing one can do here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
