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

StringIndexOutOfBoundsException on subversion checkout

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • subversion-plugin
    • Master on CentOS, issues seen on CentOS and Windows hosted slaves

      I upgraded to Jenkins 1.554.1 with Subversion plugin 2.4 yesterday and I am seeing this and similar in the build logs of some jobs trying to checkout code from subversion:

      FATAL: String index out of range: -7
java.lang.StringIndexOutOfBoundsException: String index out of range: -7
	at java.lang.String.substring(String.java:1875)
	at hudson.scm.DirAwareSVNXMLLogHandler.sendToHandler(DirAwareSVNXMLLogHandler.java:111)
	at hudson.scm.DirAwareSVNXMLLogHandler.handleLogEntry(DirAwareSVNXMLLogHandler.java:82)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:167)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:164)
	at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.handleLogEntry(SvnRemoteLog.java:199)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.logImpl(SVNRepositoryImpl.java:827)
	at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1035)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:181)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:118)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
	at hudson.model.Run.execute(Run.java:1676)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)

      Note that the index is not always -7.

      When the job is rerun the next build does the checkout no problem.

      I am aware of JENKINS-22199 and this looks very similar but JENKINS-22199 is meant to have been fixed in Subversion plugin 2.3.

          [JENKINS-23146] StringIndexOutOfBoundsException on subversion checkout

          Kevin Cross created issue -

          Daniel Beck added a comment - - edited

          Investigating.

          Probably caused by my attempt in Subversion Plugin 2.4 to resolve JENKINS-18574. In my defense, the pull request had "request for comments" in the title and was merged anyway

          Would help if you could provide the module locations in your job as well as the paths changed in SVN since the previous build. The former can be obtained by running this script in Jenkins Script Console:

          def name = 'name of the job'

def p = Jenkins.instance.getItemByFullName(name)
def scm = p.scm
scm.getProjectLocations(p).each {
  println it.remote
  println it.local
}

          Daniel Beck added a comment - - edited Investigating. Probably caused by my attempt in Subversion Plugin 2.4 to resolve JENKINS-18574 . In my defense, the pull request had "request for comments" in the title and was merged anyway Would help if you could provide the module locations in your job as well as the paths changed in SVN since the previous build. The former can be obtained by running this script in Jenkins Script Console: def name = 'name of the job' def p = Jenkins.instance.getItemByFullName(name) def scm = p.scm scm.getProjectLocations(p).each { println it.remote println it.local }
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-22199 [ JENKINS-22199 ]

          Daniel Beck added a comment -

          What a mess. I suggest you downgrade to 2.3 for the time being. Alternatively, if you want the other 2.4 features, here's a patch:

          https://github.com/daniel-beck/subversion-plugin/commit/03774c995cb53ff21a31a7bccfa79b66d087f3aa

          Daniel Beck added a comment - What a mess. I suggest you downgrade to 2.3 for the time being. Alternatively, if you want the other 2.4 features, here's a patch: https://github.com/daniel-beck/subversion-plugin/commit/03774c995cb53ff21a31a7bccfa79b66d087f3aa
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-18574 [ JENKINS-18574 ]

          Daniel Beck added a comment -

          Alternative approach that also resolves this issue, and improves JENKINS-18574:
          https://github.com/daniel-beck/subversion-plugin/commit/08ed6c99c7d762b32243bf3121f08b4229e98c8b

          • Only provide paths in the workspace via getAffectedFiles() API
          • Show both server path and local path on changes page
          • Correctly merge multiple locations checked out from the same repo

          It still has issues though:

          • Every repo path can be checked out arbitrarily often into the workspace, and this will only report one local path per repo path
          • Not tested with any externals
          • Not tested with any Windows nodes

          Daniel Beck added a comment - Alternative approach that also resolves this issue, and improves JENKINS-18574 : https://github.com/daniel-beck/subversion-plugin/commit/08ed6c99c7d762b32243bf3121f08b4229e98c8b Only provide paths in the workspace via getAffectedFiles() API Show both server path and local path on changes page Correctly merge multiple locations checked out from the same repo It still has issues though: Every repo path can be checked out arbitrarily often into the workspace, and this will only report one local path per repo path Not tested with any externals Not tested with any Windows nodes
          Daniel Beck made changes -
          Assignee New: Daniel Beck [ danielbeck ]
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-16045 [ JENKINS-16045 ]

          Kevin Cross added a comment -

          Hi Daniel,

          The output from the script in your earlier comment for one of the failed jobs is:

          svn://svn/messagingPlatform/message-processing/trunk/application-messaging-platform-message-processing
.

          In that particular job there were no scm changes.

          Kevin Cross added a comment - Hi Daniel, The output from the script in your earlier comment for one of the failed jobs is: svn: //svn/messagingPlatform/message-processing/trunk/application-messaging-platform-message-processing . In that particular job there were no scm changes.

          Daniel Beck added a comment -

          Hi Kevin,

          thanks for the info. If a build fails, it computes the changelog, and finds changed paths. Those are the interesting ones.

          My current hypothesis (on which I base the first patch linked above) is that there are relevant change sets (commits) that contain paths both inside the path that is checked out (i.e. inside .../trunk/application-messaging-platform-message-processing in your case) and outside of it. So for analysis of your issue, I need both the checked out paths (which you provide) as well as the relevant change sets' changed paths.

          Since it fails in changelog computation, and only compares current + previous build, at least every other build will succeed (as there'll be nothing to compare after a build failed during changelog computation!).

          Daniel Beck added a comment - Hi Kevin, thanks for the info. If a build fails, it computes the changelog, and finds changed paths. Those are the interesting ones. My current hypothesis (on which I base the first patch linked above) is that there are relevant change sets (commits) that contain paths both inside the path that is checked out (i.e. inside .../trunk/application-messaging-platform-message-processing in your case) and outside of it . So for analysis of your issue, I need both the checked out paths (which you provide) as well as the relevant change sets' changed paths. Since it fails in changelog computation, and only compares current + previous build, at least every other build will succeed (as there'll be nothing to compare after a build failed during changelog computation!).

            danielbeck Daniel Beck
            kevinhcross Kevin Cross
            Votes:
            60 Vote for this issue
            Watchers:
            71 Start watching this issue

              Created:
              Updated:
              Resolved: