I've been hit by this bug too, with Jenkins 2.60.3 and pipeline-model-definition 1.2.2, in a similar situation: a JobDSL-generated WorkflowJob, with a logRotator defined outside of the properties list. I will attach a config.xml too, and a stacktrace during the live lock (it's an infinite loop, with 100% cpu usage on master). The stack changed a bit because of different core and plugin versions, but I'm pretty sure the bug is the same.
Looking at the code, I think this could be the explanation:
- here, we have a loop to remove all properties of a given type
https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/pipeline-model-definition-1.2.2/pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy#L550
=> "as long as there is some property of this type, remove a property of this type"
- here the implementation of Job.getProperty(Class)
https://github.com/jenkinsci/jenkins/blob/jenkins-2.60.3/core/src/main/java/hudson/model/Job.java#L567
=> Note that it can return something which is not actually from the job properties list.
- here the implementation of Job.removeProperty(Class)
https://github.com/jenkinsci/jenkins/blob/jenkins-2.60.3/core/src/main/java/hudson/model/Job.java#L532
=> Note that it won't remove anything which was not in the properties list.
The fundamental issue here is that get and remove methods are not coherent, meaning that the assumption that "when you can get something you can also remove it" is not true. Maybe that's something that should be fixed in core, by adding a special case in removeProperty, similar to the one in getProperty.
Now, I think it's also something you could workaround in pipeline-model-definition, by not looping when removeProperty returns null. Actually, I'm not sure you need to call getProperty at all:
while (j.removeProperty(p.class) != null) {}
Can you attach the resulting Pipeline script?