[MNG-7213] StackOverflowError when version ranges are unsolvable and graph contains a cycle

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.6.3, 3.8.1
• Fix Version/s: 3.9.1, 4.0.0-alpha-5, 4.0.0
• Component/s: Artifacts and Repositories
• Assignee: Tamas Cservenak
• Reporter: Henrik Rueping
• Created: 13/Aug/21 12:45
• Updated: 23/Feb/23 11:44
• Resolved: 23/Feb/23 08:52

Description

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:

 

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...)

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.

Issue Links

• is caused by: MRESOLVER-316 DF collector enters endless loop when collecting org.webjars.npm:musquette:1.1.1
• is fixed by: MNG-7695 Upgrade to resolver 1.9.5