[JENKINS-76202] stack overflow with maven and naginator plugins in AbstractLazyLoadRunMap with new runUI enabled

[jenkins-infra-bot]

Seems the rework of the AbstractLazyLoadRunMap caused problems when there is a maven type job with some builds and the naginator plugin.
With this combination, when accessing the dashboard that contains a maven job Jenkins runs into a stack overflow.

at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:27)
at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:16)
at hudson.model.Actionable.createFor(Actionable.java:118)
at hudson.model.Actionable.getAllActions(Actionable.java:104)
at hudson.model.Run.onLoad(Run.java:390)
at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.onLoad(MavenModuleSetBuild.java:154)
at hudson.model.RunMap.retrieve(RunMap.java:290)
at hudson.model.RunMap.retrieve(RunMap.java:64)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:451)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:445)
at jenkins.model.lazy.AbstractLazyLoadRunMap.resolveBuildRef(AbstractLazyLoadRunMap.java:371)
at jenkins.model.lazy.AbstractLazyLoadRunMap$BuildReferenceMapAdapterResolver.resolveBuildRef(AbstractLazyLoadRunMap.java:528)
at jenkins.model.lazy.BuildReferenceMapAdapter.get(BuildReferenceMapAdapter.java:133)
at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:387)
at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:243)
at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:932)
at PluginClassLoader for maven-plugin//hudson.maven.MavenBuild.getParentBuild(MavenBuild.java:186)
at PluginClassLoader for maven-plugin//hudson.maven.FilteredChangeLogSet.(FilteredChangeLogSet.java:45)
at PluginClassLoader for maven-plugin//hudson.maven.MavenBuild.getChangeSet(MavenBuild.java:213)
at hudson.model.AbstractBuild.getChangeSets(AbstractBuild.java:929)
at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:55)
at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:37)
at hudson.model.Actionable.createFor(Actionable.java:118)
at hudson.model.Actionable.getAllActions(Actionable.java:104)
at hudson.model.Run.onLoad(Run.java:390)
at hudson.model.RunMap.retrieve(RunMap.java:290)
at hudson.model.RunMap.retrieve(RunMap.java:64)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:451)
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:445)
at jenkins.model.lazy.AbstractLazyLoadRunMap.resolveBuildRef(AbstractLazyLoadRunMap.java:371)
at jenkins.model.lazy.AbstractLazyLoadRunMap$BuildReferenceMapAdapterResolver.resolveBuildRef(AbstractLazyLoadRunMap.java:528)
at jenkins.model.lazy.BuildReferenceMapAdapter$EntryAdapter.getValue(BuildReferenceMapAdapter.java:345)
at jenkins.model.lazy.BuildReferenceMapAdapter$ValuesAdapter$1.adapt(BuildReferenceMapAdapter.java:231)
at jenkins.model.lazy.BuildReferenceMapAdapter$ValuesAdapter$1.adapt(BuildReferenceMapAdapter.java:228)
at hudson.util.AdaptedIterator.next(AdaptedIterator.java:57)
at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1950)
at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:342)
at jenkins.model.lazy.LazyBuildMixIn.getNearestOldBuild(LazyBuildMixIn.java:271)
at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:957)
at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:499)
at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.computeResult(MavenModuleSetBuild.java:227)
at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:216)
at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:27)
at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:16)

Might be related to JENKINS-76028

 

Removing the naginator plugin resolves the problem

---

Originally reported by mawinter69, imported from: stack overflow with maven and naginator plugins in AbstractLazyLoadRunMap with new runUI enabled

• assignee: mawinter69
• status: Closed
• priority: Major
• component(s): core, maven-plugin, naginator-plugin
• resolution: Fixed
• resolved: 2025-10-16T17:19:15+00:00
• votes: 0
• watchers: 5
• imported: 2025-11-24

Raw content of original issue

Seems the rework of the AbstractLazyLoadRunMap caused problems when there is a maven type job with some builds and the naginator plugin.
With this combination, when accessing the dashboard that contains a maven job Jenkins runs into a stack overflow.

        at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:27)
        at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:16)
        at hudson.model.Actionable.createFor(Actionable.java:118)
        at hudson.model.Actionable.getAllActions(Actionable.java:104)
        at hudson.model.Run.onLoad(Run.java:390)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.onLoad(MavenModuleSetBuild.java:154)
        at hudson.model.RunMap.retrieve(RunMap.java:290)
        at hudson.model.RunMap.retrieve(RunMap.java:64)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:451)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:445)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.resolveBuildRef(AbstractLazyLoadRunMap.java:371)
        at jenkins.model.lazy.AbstractLazyLoadRunMap$BuildReferenceMapAdapterResolver.resolveBuildRef(AbstractLazyLoadRunMap.java:528)
        at jenkins.model.lazy.BuildReferenceMapAdapter.get(BuildReferenceMapAdapter.java:133)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:387)
        at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:243)
        at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:932)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenBuild.getParentBuild(MavenBuild.java:186)
        at PluginClassLoader for maven-plugin//hudson.maven.FilteredChangeLogSet.<init>(FilteredChangeLogSet.java:45)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenBuild.getChangeSet(MavenBuild.java:213)
        at hudson.model.AbstractBuild.getChangeSets(AbstractBuild.java:929)
        at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:55)
        at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:37)
        at hudson.model.Actionable.createFor(Actionable.java:118)
        at hudson.model.Actionable.getAllActions(Actionable.java:104)
        at hudson.model.Run.onLoad(Run.java:390)
        at hudson.model.RunMap.retrieve(RunMap.java:290)
        at hudson.model.RunMap.retrieve(RunMap.java:64)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:451)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:445)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.resolveBuildRef(AbstractLazyLoadRunMap.java:371)
        at jenkins.model.lazy.AbstractLazyLoadRunMap$BuildReferenceMapAdapterResolver.resolveBuildRef(AbstractLazyLoadRunMap.java:528)
        at jenkins.model.lazy.BuildReferenceMapAdapter$EntryAdapter.getValue(BuildReferenceMapAdapter.java:345)
        at jenkins.model.lazy.BuildReferenceMapAdapter$ValuesAdapter$1.adapt(BuildReferenceMapAdapter.java:231)
        at jenkins.model.lazy.BuildReferenceMapAdapter$ValuesAdapter$1.adapt(BuildReferenceMapAdapter.java:228)
        at hudson.util.AdaptedIterator.next(AdaptedIterator.java:57)
        at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1950)
        at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
        at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
        at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:342)
        at jenkins.model.lazy.LazyBuildMixIn.getNearestOldBuild(LazyBuildMixIn.java:271)
        at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:957)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:499)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.computeResult(MavenModuleSetBuild.java:227)
        at PluginClassLoader for maven-plugin//hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:216)
        at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:27)
        at PluginClassLoader for naginator//com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:16)

Might be related to JENKINS-76028
 
Removing the naginator plugin resolves the problem

1 attachment

• stacktrace.txt

[jenkins-infra-bot]

• Remote link associated with this issue:

  • PR-11203

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Whatever the cause, I suspect one fix (which would also generally improve performance) would be
  
  
  diff --git core/src/main/java/hudson/model/Run.java core/src/main/java/hudson/model/Run.java
  index b0b72dda08..c206539a46 100644
  --- core/src/main/java/hudson/model/Run.java
  +++ core/src/main/java/hudson/model/Run.java
  @@ -387,7 +387,7 @@ public abstract class Run<JobT extends Job<JobT, RunT>, RunT extends Run<JobT, R
        */
       @SuppressWarnings("deprecation")
       protected void onLoad() {
  -        for (Action a : getAllActions()) {
  +        for (Action a : getActions()) {
               if (a instanceof RunAction2) {
                   try {
                       ((RunAction2) a).onLoad(this);
  
  
  (A transient action has no business being a RunAction2 to begin with.)
  

Whatever the cause, I suspect one fix (which would also generally improve performance) would be

diff --git core/src/main/java/hudson/model/Run.java core/src/main/java/hudson/model/Run.java
index b0b72dda08..c206539a46 100644
--- core/src/main/java/hudson/model/Run.java
+++ core/src/main/java/hudson/model/Run.java
@@ -387,7 +387,7 @@ public abstract class Runextends Job, RunT extends Run"deprecation")
     protected void onLoad() {
-for (Action a : getAllActions()) {
+for (Action a : getActions()) {
     if (a instanceof RunAction2) {
 try {
     ((RunAction2) a).onLoad(this);

(A transient action has no business being a RunAction2 to begin with.)

[jenkins-infra-bot]

dukhlov:

• Original comment link
• Raw content of original comment:

  It appears that the issue stems from MavenModuleSetBuild.onLoad() recursively triggering the loading of all previous builds. If the build history is long enough, this can eventually lead to a StackOverflowException.
  
  This problem likely existed even before the recent lazy loading refactor, but it was previously masked by the inefficient implementation of lazy loading (possibly because builds were being loaded in ascending order at that stage of execution.
  

It appears that the issue stems from MavenModuleSetBuild.onLoad() recursively triggering the loading of all previous builds. If the build history is long enough, this can eventually lead to a StackOverflowException.

This problem likely existed even before the recent lazy loading refactor, but it was previously masked by the inefficient implementation of lazy loading (possibly because builds were being loaded in ascending order at that stage of execution.

[jenkins-infra-bot]

dukhlov:

• Original comment link
• Raw content of original comment:

  jglick's fix looks good, should stop recursive parent build loading 
  

jglick's fix looks good, should stop recursive parent build loading 

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  I've not been able to duplicate the issue in my local testing.  mawinter69 can you provide more details so that others can duplicate it?  Specifically, which page do you open when you say that you are opening the dashboard?
  
  I created a Maven job that built the Jenkins platformlabeler plugin but only running InjectedTest rather than all tests and then called a freestyle job.  I configured the freestyle job to call the Maven job so that they were building in a loop.  I interrupted the loop after 200+ builds of the platformlabeler plugin and was unable to see a stack overflow exception in any of my browsing.
  

I've not been able to duplicate the issue in my local testing. mawinter69 can you provide more details so that others can duplicate it? Specifically, which page do you open when you say that you are opening the dashboard?

I created a Maven job that built the Jenkins platformlabeler plugin but only running InjectedTest rather than all tests and then called a freestyle job. I configured the freestyle job to call the Maven job so that they were building in a loop. I interrupted the loop after 200+ builds of the platformlabeler plugin and was unable to see a stack overflow exception in any of my browsing.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  markewaite and I guess you included the Naginator plugin. Even with that, I would not expect this to be reproducible easily since it would depend on what builds happened to be in memory, and the structure of Maven modules in a reactor (you might need to enable some option to select that behavior).
  
  There is a lot at fault in the stack trace, mostly in the maven-plugin craziness of nested projects; the Run.onLoad behavior just seems easiest to change.
  

markewaite and I guess you included the Naginator plugin. Even with that, I would not expect this to be reproducible easily since it would depend on what builds happened to be in memory, and the structure of Maven modules in a reactor (you might need to enable some option to select that behavior).

There is a lot at fault in the stack trace, mostly in the maven-plugin craziness of nested projects; the Run.onLoad behavior just seems easiest to change.

[jenkins-infra-bot]

dukhlov:

• Original comment link
• Raw content of original comment:

  markewaite, theoretically, if you have a job with an empty build history, and then run builds one by one the issue won't be reproduced. You have to have a long build history not loaded yet. For example if you restart the jenkins after your test (when 200 builds exist on the disk) may cause the StackOverflow issue. Also using -Djenkins.model.lazy.BuildReference.MODE=weak or -Djenkins.model.lazy.BuildReference.MODE=none may help to reproduce
  

markewaite, theoretically, if you have a job with an empty build history, and then run builds one by one the issue won't be reproduced. You have to have a long build history not loaded yet. For example if you restart the jenkins after your test (when 200 builds exist on the disk) may cause the StackOverflow issue. Also using -Djenkins.model.lazy.BuildReference.MODE=weak or -Djenkins.model.lazy.BuildReference.MODE=none may help to reproduce

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  I have just 4 runs in the maven project. So this is not due to too many runs.
  

I have just 4 runs in the maven project. So this is not due to too many runs.

[jenkins-infra-bot]

dukhlov:

• Original comment link
• Raw content of original comment:

  mawinter69, may I ask you to attach the whole stack trace?
  

mawinter69, may I ask you to attach the whole stack trace?

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  I think the issue is related to the new run ui pages.
  
  at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:55)
  
  At least I can see the issue only after a restart with the new run UI enabled. But then it is a real issue. Accessing the maven job fails to load the builds widget in the sidepanel. 
  With the new UI disabled everything works fine.
  

I think the issue is related to the new run ui pages.

at jenkins.run.ChangesTabFactory.createFor(ChangesTabFactory.java:55)

At least I can see the issue only after a restart with the new run UI enabled. But then it is a real issue. Accessing the maven job fails to load the builds widget in the sidepanel. 

With the new UI disabled everything works fine.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  There is a lot at fault in the stack trace, mostly in the maven-plugin craziness of nested projects; the Run.onLoad behavior just seems easiest to change.
  
  I think that suggests strongly that I don't need to duplicate the issue, but rather we should have mawinter69 confirm that the proposed fix resolves the issue in his environment.  mawinter69 are you willing to apply that change to a local build of Jenkins core and confirm that it resolves the issue?
  

There is a lot at fault in the stack trace, mostly in the maven-plugin craziness of nested projects; the Run.onLoad behavior just seems easiest to change.

I think that suggests strongly that I don't need to duplicate the issue, but rather we should have mawinter69 confirm that the proposed fix resolves the issue in his environment. mawinter69 are you willing to apply that change to a local build of Jenkins core and confirm that it resolves the issue?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  issue only after a restart with the new run UI enabled
  
  I was definitely not using the new run UI.  Thanks for that clarity.  When I enable the new run UI, I see the stack overflow error in the Jenkins console log.
  

issue only after a restart with the new run UI enabled

I was definitely not using the new run UI. Thanks for that clarity. When I enable the new run UI, I see the stack overflow error in the Jenkins console log.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  While I think the Run.onLoad change is a good idea generally, a particular problem here is that 
  
    
  
      
  
        jenkins/core/src/main/java/jenkins/run/ChangesTabFactory.java
      
      
  
          Lines 54 to 61
        in
        c44796d
      
    
    
  
      
  
  
          
  
            
  
            
   if (target instanceof RunWithSCM<?, ?> targetWithSCM) { 
          
  
          
  
            
  
            
       var hasChangeSet = !targetWithSCM.getChangeSets().isEmpty(); 
          
  
          
  
            
  
            
       if (hasChangeSet) { 
          
  
          
  
            
  
            
           return Collections.singleton(new ChangesTab(target)); 
          
  
          
  
            
  
            
       } 
          
  
          
  
            
  
            
   } 
          
  
          
  
            
  
            
    
          
  
          
  
            
  
            
   return Collections.emptySet(); 
          
      
    
  
   is trying to be unnecessarily clever. It could just unconditionally return a ChangesTab, and then for example 
  
    
  
      
  
        jenkins/core/src/main/java/jenkins/run/ChangesTab.java
      
      
  
          Lines 46 to 49
        in
        c44796d
      
    
    
  
      
  
  
          
  
            
  
            
   @Override 
          
  
          
  
            
  
            
   public String getUrlName() { 
          
  
          
  
            
  
            
       return "changes"; 
          
  
          
  
            
  
            
   } 
          
      
    
  
   could dynamically return null to hide itself in case the associated build has no change sets, checked if and when an attempt is actually made to display the action. TransientActionFactory.createFor should avoid doing any significant computation; always err on the side of producing an Action, and let it be empty/hidden/no-op lazily.
  
  

While I think the Run.onLoad change is a good idea generally, a particular problem here is that

jenkins/core/src/main/java/jenkins/run/ChangesTabFactory.java

Lines 54 to 61 in c44796d

	if (target instanceof RunWithSCM<?, ?> targetWithSCM) {
	var hasChangeSet = !targetWithSCM.getChangeSets().isEmpty();
	if (hasChangeSet) {
	return Collections.singleton(new ChangesTab(target));
	}
	}
	return Collections.emptySet();

is trying to be unnecessarily clever. It could just unconditionally return a ChangesTab, and then for example

jenkins/core/src/main/java/jenkins/run/ChangesTab.java

Lines 46 to 49 in c44796d

	@Override
	public String getUrlName() {
	return "changes";
	}

could dynamically return null to hide itself in case the associated build has no change sets, checked if and when an attempt is actually made to display the action. TransientActionFactory.createFor should avoid doing any significant computation; always err on the side of producing an Action, and let it be empty/hidden/no-op lazily.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Markus Winter are you willing to apply that change to a local build of Jenkins core and confirm that it resolves the issue?
  
  I've confirmed that Jesse's change resolves the issue.  
  
  Since it seems to only be visible when the experimental UI is visible, I think it is a good candidate to fix in a weekly release.  I don't yet see a reason to backport the fix to the 2.528.x LTS line, but I'm open to be persuaded that we should backport it even though it seems to only be visible with the experimental run UI.
  

Markus Winter are you willing to apply that change to a local build of Jenkins core and confirm that it resolves the issue?

I've confirmed that Jesse's change resolves the issue.

Since it seems to only be visible when the experimental UI is visible, I think it is a good candidate to fix in a weekly release. I don't yet see a reason to backport the fix to the 2.528.x LTS line, but I'm open to be persuaded that we should backport it even though it seems to only be visible with the experimental run UI.

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  I can confirm that the proposed change by jglick solves the problem.
  

I can confirm that the proposed change by jglick solves the problem.