| The problem does not occur with an older jenkins version (around 2.190), and so I believe the bug does appear now due to some changes in the core. I did only a static analyzation of the generated call stack by folling the source code, no debugging ... I do not know why the first check does not suceed before the configuration is loaded at startup. And yes, the possibility for the loop itself is in the code for 3 years. Checking the authorization in a method that is called when reading the authorization configuration is not a good idea, if the check will result in reading the config again ... Here are some log lines, when starting jenkins ... I have shortened the call stacks. Maybe this will help to get down to the problem ... 2020-04-29 07:14:31.980+0000 [id=34] INFO jenkins.InitReactorRunner$1#onAttained: Prepared all plugins 2020-04-29 07:14:31.980+0000 [id=34] INFO jenkins.InitReactorRunner$1#onAttained: Prepared all plugins 2020-04-29 07:14:31.984+0000 [id=29] INFO jenkins.model.Jenkins$5#runTask: Took 0ms for null by pool-6-thread-1 2020-04-29 07:14:31.984+0000 [id=29] INFO jenkins.model.Jenkins$5#runTask: Took 0ms for null by pool-6-thread-1 2020-04-29 07:14:31.992+0000 [id=31] INFO jenkins.model.Jenkins$5#runTask: Took 8ms for Contributed.load by pool-6-thread-3 2020-04-29 07:14:32.117+0000 [id=34] INFO jenkins.model.Jenkins$5#runTask: Took 133ms for Resolving Dependent Plugins Graph by pool-6-thread-6 2020-04-29 07:14:33.204+0000 [id=39] WARNING hudson.model.Descriptor#load: Failed to load D:\Jenkins\jenkins.security.QueueItemAuthenticatorConfiguration.xml java.lang.StackOverflowError at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:344) ... |