Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15702

InstantiationError: hudson.scm.AbstractCvs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: cvs-plugin
    • Labels:
      None
    • Environment:
      Jenkins v1.487
    • Similar Issues:

      Description

      Getting the following in the system log at startup. Not sure of the ramifications.

      Nov 2, 2012 9:23:30 AM hudson.util.RobustReflectionConverter doUnmarshal
      WARNING: Failed to resolve a type
      java.lang.InstantiationError: hudson.scm.AbstractCvs
      at sun.reflect.GeneratedSerializationConstructorAccessor507.newInstance(Unknown Source)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
      at com.thoughtworks.xstream.converters.reflection.Sun14ReflectionProvider.newInstance(Sun14ReflectionProvider.java:76)
      at hudson.util.RobustReflectionConverter.instantiateNewInstance(RobustReflectionConverter.java:375)
      at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:220)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
      at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
      at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332)
      at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274)
      at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
      at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
      at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)
      at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85)
      at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61)
      at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
      at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
      at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:332)
      at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:274)
      at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:221)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
      at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
      at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
      at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
      at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:926)
      at hudson.util.XStream2.unmarshal(XStream2.java:103)
      at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:912)
      at hudson.XmlFile.unmarshal(XmlFile.java:160)
      at hudson.model.Run.reload(Run.java:291)
      at hudson.model.Run.<init>(Run.java:280)
      at hudson.model.AbstractBuild.<init>(AbstractBuild.java:182)
      at hudson.model.Build.<init>(Build.java:103)
      at hudson.model.FreeStyleBuild.<init>(FreeStyleBuild.java:41)
      at sun.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
      at hudson.model.AbstractProject.loadBuild(AbstractProject.java:1061)
      at hudson.model.AbstractProject$1.create(AbstractProject.java:275)
      at hudson.model.AbstractProject$1.create(AbstractProject.java:273)
      at hudson.model.RunMap.retrieve(RunMap.java:220)
      at hudson.model.RunMap.retrieve(RunMap.java:59)
      at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638)
      at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621)
      at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:574)
      at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:240)
      at java.util.AbstractMap$2$1.<init>(AbstractMap.java:353)
      at java.util.AbstractMap$2.iterator(AbstractMap.java:352)
      at hudson.util.RunList.iterator(RunList.java:103)
      at org.jvnet.hudson.plugins.DownStreamProjectActionFactory.createFor(DownStreamProjectActionFactory.java:59)
      at hudson.model.AbstractProject.createTransientActions(AbstractProject.java:675)
      at hudson.model.Project.createTransientActions(Project.java:208)
      at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:665)
      at hudson.model.AbstractProject.onLoad(AbstractProject.java:299)
      at hudson.model.Project.onLoad(Project.java:88)
      at hudson.model.Items.load(Items.java:221)
      at jenkins.model.Jenkins$17.run(Jenkins.java:2507)
      at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
      at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
      at jenkins.model.Jenkins$7.runTask(Jenkins.java:883)
      at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
      at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:662)

        Attachments

          Activity

          Hide
          johnwcoyote John M added a comment -

          I ran into this problem during an upgrade to CVS Plugin 2.7 with Jenkins 1.5. The server appeared to be hung up on start up and was writing tremendous log files due to this WARNING stacktrace appearing over and over. We have 170 jobs and close to 12,000 builds.

          It came down to one line in the jenkins build.xml file which sits inside the build folders. This is what part of an existing build.xml file looked like:

          <hudson.scm.cvstagging.CvsTagAction>
          <build class="build" reference="../../.."/>
          <tagNames/>
          <parent>

          In a new job, this section of the build file looked like this

          <hudson.scm.cvstagging.CvsTagAction plugin="cvs@2.7">
          <build class="build" reference="../../.."/>
          <tagNames/>
          <parent class="hudson.scm.CVSSCM">

          After updating the <parent> element in the old files to match <parent class="hudson.scm.CVSSCM"> and restarting the server, the log warnings went away. Adding the plugin attribute to the CvsTagAction element in the older build xml files did not have any effect.

          Show
          johnwcoyote John M added a comment - I ran into this problem during an upgrade to CVS Plugin 2.7 with Jenkins 1.5. The server appeared to be hung up on start up and was writing tremendous log files due to this WARNING stacktrace appearing over and over. We have 170 jobs and close to 12,000 builds. It came down to one line in the jenkins build.xml file which sits inside the build folders. This is what part of an existing build.xml file looked like: <hudson.scm.cvstagging.CvsTagAction> <build class="build" reference="../../.."/> <tagNames/> <parent> In a new job, this section of the build file looked like this <hudson.scm.cvstagging.CvsTagAction plugin="cvs@2.7"> <build class="build" reference="../../.."/> <tagNames/> <parent class="hudson.scm.CVSSCM"> After updating the <parent> element in the old files to match <parent class="hudson.scm.CVSSCM"> and restarting the server, the log warnings went away. Adding the plugin attribute to the CvsTagAction element in the older build xml files did not have any effect.
          Hide
          mc1arke Michael Clarke added a comment -

          John - what version of CVS plugin were these builds created with?

          Show
          mc1arke Michael Clarke added a comment - John - what version of CVS plugin were these builds created with?
          Hide
          johnwcoyote John M added a comment - - edited

          Hi,

          It was a 2.6 SNAPSHOT from sometime in Aug 2012.

          I realize the fact we were using a snapshot was taking a risk and made the problem our responsibility.

          I hope it was useful to report that we saw this same behavior and found a solution.

          Thanks

          Show
          johnwcoyote John M added a comment - - edited Hi, It was a 2.6 SNAPSHOT from sometime in Aug 2012. I realize the fact we were using a snapshot was taking a risk and made the problem our responsibility. I hope it was useful to report that we saw this same behavior and found a solution. Thanks
          Hide
          mc1arke Michael Clarke added a comment -

          I have no issue with you using a snapshot. Your report has helped me confirm where the issue lies so there's been no issue with you reporting against a snapshot version. The change has been caused by the abstraction of functionality to support CVS projectets and the subsequent change to the Cvs Tagging code to change fields from being defined as concrete type to an abstract type. Any builds that have been performed with the plugin since this change are ok since serialization saves a record of what the actual type is (CVSSCM or CvsProjectset) but builds completed before this change assume they should create an exact instance of the field type which isn't possible since they type isn't a concrete class.

          The big issue is how to fix this. One option is to leave functionality as it currently is knowing old builds fail whilst loading tagging (although also possibly add some code to remove the failed data from the config so the error doesn't happen every time Jenkins restarts). The second option is to revert the change to the field type with additional code to dynamically upgrade to a differently named abstract field as each build is loaded. This will cause anyone using CvsProjectset to get this error for builds performed before a release of the plugin with the fix. My personal preference would be to break functionality for CvsProjectset users since this should have far fewer completed builds to error out on, although arguably these builds are newer than any that may be recovered by fixing this for older builds.

          For those of you watching this issue, do you have any thoughts or preference on this?

          For reference, the problem line of code is: https://github.com/jenkinsci/cvs-plugin/blob/master/src/main/java/hudson/scm/cvstagging/CvsTagAction.java#L52

          Show
          mc1arke Michael Clarke added a comment - I have no issue with you using a snapshot. Your report has helped me confirm where the issue lies so there's been no issue with you reporting against a snapshot version. The change has been caused by the abstraction of functionality to support CVS projectets and the subsequent change to the Cvs Tagging code to change fields from being defined as concrete type to an abstract type. Any builds that have been performed with the plugin since this change are ok since serialization saves a record of what the actual type is (CVSSCM or CvsProjectset) but builds completed before this change assume they should create an exact instance of the field type which isn't possible since they type isn't a concrete class. The big issue is how to fix this. One option is to leave functionality as it currently is knowing old builds fail whilst loading tagging (although also possibly add some code to remove the failed data from the config so the error doesn't happen every time Jenkins restarts). The second option is to revert the change to the field type with additional code to dynamically upgrade to a differently named abstract field as each build is loaded. This will cause anyone using CvsProjectset to get this error for builds performed before a release of the plugin with the fix. My personal preference would be to break functionality for CvsProjectset users since this should have far fewer completed builds to error out on, although arguably these builds are newer than any that may be recovered by fixing this for older builds. For those of you watching this issue, do you have any thoughts or preference on this? For reference, the problem line of code is: https://github.com/jenkinsci/cvs-plugin/blob/master/src/main/java/hudson/scm/cvstagging/CvsTagAction.java#L52
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Michael Clarke
          Path:
          src/main/java/hudson/scm/cvstagging/CvsTagAction.java
          http://jenkins-ci.org/commit/cvs-plugin/e14b9e37583f9004ae676bd023b933d95550a18a
          Log:
          [FIXED JENKINS-15702] convert tag data to new structure

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/cvstagging/CvsTagAction.java http://jenkins-ci.org/commit/cvs-plugin/e14b9e37583f9004ae676bd023b933d95550a18a Log: [FIXED JENKINS-15702] convert tag data to new structure

            People

            • Assignee:
              mc1arke Michael Clarke
              Reporter:
              daehren David Ehrenberger
            • Votes:
              2 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: