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

ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None

      After updating to Jenkins 1.599/Subversion plugin 2.5, every other build of various jobs throws the exception

      Updating svn://... at revision '2015-02-22T22:24:56.096 +0100'
      At revision 224551
      FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
      java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState
      	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
      	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
      	at hudson.scm.SCM.checkout(SCM.java:484)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
      	at hudson.model.Run.execute(Run.java:1718)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      	at hudson.model.ResourceController.execute(ResourceController.java:89)
      	at hudson.model.Executor.run(Executor.java:240)
      

          [JENKINS-27079] ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState

          jenkins_mizuho Please, avoid to paste the same comment in different JIRA issues.

          Manuel Recena Soto added a comment - jenkins_mizuho Please, avoid to paste the same comment in different JIRA issues.

          Anthony Mastrean added a comment - - edited

          I run Jenkins 1.633 with the Subversion plugin 2.5. When I checkout a large repository (100K+ revisions) in a configuration with a clean workspace (this seems important?), I get the following error. The second run of the same configuration seems to always succeed.

          FATAL: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState
          java.lang.ClassCastException: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState
          	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
          	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
          	at hudson.scm.SCM.checkout(SCM.java:485)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
          	at hudson.model.Run.execute(Run.java:1741)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          	at hudson.model.ResourceController.execute(ResourceController.java:98)
          	at hudson.model.Executor.run(Executor.java:408)
          

          It always seems to checkout (using update as much as possible) to the top-level directory, which indicates a complete checkout. Then it fails

           U        .
          At revision 107500
          

          Anthony Mastrean added a comment - - edited I run Jenkins 1.633 with the Subversion plugin 2.5. When I checkout a large repository (100K+ revisions) in a configuration with a clean workspace (this seems important?), I get the following error. The second run of the same configuration seems to always succeed. FATAL: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState java.lang.ClassCastException: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408) It always seems to checkout (using update as much as possible) to the top-level directory, which indicates a complete checkout. Then it fails U . At revision 107500

          Cannot reproduce: Jenkins 2.16, multiple-scms 0.6, Subversion Plug-in 2.6

          Craig Rodrigues added a comment - Cannot reproduce: Jenkins 2.16, multiple-scms 0.6, Subversion Plug-in 2.6

          Jeff Dafoe added a comment -

          We just switched from Git to SVN and I can repro this on the first build of every project as I switch them to SVN. The first build fails with the error anthonymastrean posted and similar to his experience, subsequent builds work fine. If it's any help, our SVN repo is on revision 1 and has no changes currently.

          Jeff Dafoe added a comment - We just switched from Git to SVN and I can repro this on the first build of every project as I switch them to SVN. The first build fails with the error anthonymastrean posted and similar to his experience, subsequent builds work fine. If it's any help, our SVN repo is on revision 1 and has no changes currently.

          Jeff Dafoe added a comment -

          Reopening, can repro consistently.

          Jeff Dafoe added a comment - Reopening, can repro consistently.

          Michael Breu added a comment -

          Same for me: About every 10th job fails with this error. Just now with Jenkins 2.65 /

          Subversion Plugin 2.7.2

           

          Michael

           

          Michael Breu added a comment - Same for me: About every 10th job fails with this error. Just now with Jenkins 2.65 / Subversion Plugin 2.7.2   Michael  

          Gyu-bum Choi added a comment -

          Every first time started 'Jenkins', every item, this error occured.

          Gyu-bum Choi added a comment - Every first time started 'Jenkins', every item, this error occured.

          Yan Pak added a comment - - edited

          I had the same problem. Every n-th build was failed with ClassCastException error.

          I have solved this issue by changing code in the hudson.scm.SubversionSCM.java

          Source code I took here http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/subversion/2.12.1/

           

          Was:

          boolean created;
          try {
              created = new SubversionChangeLogBuilder(build, workspace, (SVNRevisionState) baseline, env, listener, this).run(externalsMap, new StreamResult(os));
          } finally {
              os.close();
          }
          if(!created)
              createEmptyChangeLog(changelogFile, listener, "log");
          

           

          Become:

          boolean created = false;
          try {
              if(baseline instanceof SVNRevisionState){
                  created = new SubversionChangeLogBuilder(build, workspace, (SVNRevisionState) baseline, env, listener, this).run(externalsMap, new StreamResult(os));
              }
          } finally {
              os.close();
          }
          if(!created)
              createEmptyChangeLog(changelogFile, listener, "log");
          

          As you can see I added class check.

          I don't know is it absolutely right way to fix this problem, cause I don't have a whole application architecture view in my mind. It's strange that sometimes argument for new SubversionChangeLogBuilder got not castable to SVNRevisionState. Think this is flaw in the class modelling or plugin development.

          Good thing that the algorythm of this method permits also no creation of changes log (the purpoise of this failing (sometimes) method is the creation of a changes log after a checkout or an update operation), so I can think that if baseline do not casting into SVNRevisionState then result of this method should not be look as succesful creation of changes log object (created is false). So, this gives me hope that my solution is valid at last.

          I hope my pull request #228 will soon accepted. Now I have my own fixed subversion.jpi If want - write me here.

          I tested my solution. Works fine!
          No more errors like: FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState

          Yan Pak added a comment - - edited I had the same problem. Every n-th build was failed with ClassCastException error. I have solved this issue by changing code in the hudson.scm.SubversionSCM.java Source code I took here http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/subversion/2.12.1/   Was: boolean created; try { created = new SubversionChangeLogBuilder(build, workspace, (SVNRevisionState) baseline, env, listener, this ).run(externalsMap, new StreamResult(os)); } finally { os.close(); } if (!created) createEmptyChangeLog(changelogFile, listener, "log" );   Become: boolean created = false ; try { if (baseline instanceof SVNRevisionState){ created = new SubversionChangeLogBuilder(build, workspace, (SVNRevisionState) baseline, env, listener, this ).run(externalsMap, new StreamResult(os)); } } finally { os.close(); } if (!created) createEmptyChangeLog(changelogFile, listener, "log" ); As you can see I added class check. I don't know is it absolutely right way to fix this problem, cause I don't have a whole application architecture view in my mind. It's strange that sometimes argument for new SubversionChangeLogBuilder got not castable to SVNRevisionState. Think this is flaw in the class modelling or plugin development. Good thing that the algorythm of this method permits also no creation of changes log (the purpoise of this failing (sometimes) method is the creation of a changes log after a checkout or an update operation), so I can think that if baseline do not casting into SVNRevisionState then result of this method should not be look as succesful creation of changes log object ( created is false). So, this gives me hope that my solution is valid at last. I hope my pull request #228 will soon accepted. Now I have my own fixed subversion.jpi If want - write me here. I tested my solution. Works fine! No more errors like: FATAL: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState

          Yan Pak added a comment -

          Here you can download fixed version of subversion-plugin

          Put it into the Jenkins's plugin folder and restart Jenkins.

          Yan Pak added a comment - Here you can download fixed version of subversion-plugin Put it into the Jenkins's plugin folder and restart Jenkins.

          Jesse Glick added a comment -

          There are several distinct exception messages here, which are likely unrelated:

          • java.lang.ClassCastException: org.jenkinsci.plugins.multiplescms.MultiSCMRevisionState cannot be cast to hudson.scm.SVNRevisionState sounds like a bug in the Multiple SCMs plugin. Please file separately with steps to reproduce from scratch if you have them.
          • java.lang.ClassCastException: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState might be a bug in this plugin, or in Jenkins core. Smells like an upgrade problem, or a problem with the first build of a job, or something like that. Please file separately with steps to reproduce from scratch if you have them.
          • The originally reported java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState which suggests a problem in class loading—two copies of the Subversion plugin being loaded under different names, or some other plugin copying classes from this one for unknown reasons. To begin diagnosis, try bisecting your $JENKINS_HOME/plugins/ directory, or it may be possible to use /script to inspect resources multiply available from UberClassLoader.

          Jesse Glick added a comment - There are several distinct exception messages here, which are likely unrelated: java.lang.ClassCastException: org.jenkinsci.plugins.multiplescms.MultiSCMRevisionState cannot be cast to hudson.scm.SVNRevisionState sounds like a bug in the Multiple SCMs plugin. Please file separately with steps to reproduce from scratch if you have them. java.lang.ClassCastException: hudson.scm.SCMRevisionState$None cannot be cast to hudson.scm.SVNRevisionState might be a bug in this plugin, or in Jenkins core. Smells like an upgrade problem, or a problem with the first build of a job, or something like that. Please file separately with steps to reproduce from scratch if you have them. The originally reported java.lang.ClassCastException: hudson.scm.SVNRevisionState cannot be cast to hudson.scm.SVNRevisionState which suggests a problem in class loading —two copies of the Subversion plugin being loaded under different names, or some other plugin copying classes from this one for unknown reasons. To begin diagnosis, try bisecting your $JENKINS_HOME/plugins/ directory, or it may be possible to use /script to inspect resources multiply available from UberClassLoader .

            Unassigned Unassigned
            alexanderv Alexander Veit
            Votes:
            17 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated: