• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • subversion-plugin
    • None
    • OpenJDK 1.7.0_79-b14, Linux

      build failed due to SVN checkout crash.
      please see trace below:

      no revision recorded for svn://subversion/<real file name wad removed> in the previous build
      FATAL: null
      java.lang.NullPointerException
      at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:136)
      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:1284)
      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:381)

          [JENKINS-29724] SVN checkout crashes

          dimagr Could you provide more information? I can not produce the bug with this information.

          Manuel Recena Soto added a comment - dimagr Could you provide more information? I can not produce the bug with this information.

          Gerwin Jansen added a comment -

          I'm facing the same issue in 1.609.3 with SVN plugin 2.5.3.
          The NullPointerException is comming from line 122 (context = null):

          hudson.scm.SubversionChangeLogBuilder
          PathContext context = getUrlForPath(workspace.child(l.getLocalDir()), authProvider);
          context.moduleWorkspacePath = l.getLocalDir();
          

          Apparently getUrlForPath returns null. The implementation is:

          hudson.scm.SubversionChangeLogBuilder
          return path.act(new GetContextForPath(authProvider));
          

          So GetContextForPath callable returns null. The implementation is:

          hudson.scm.SubversionChangeLogBuilder
          try {
              info = svnwc.doInfo(p, SVNRevision.WORKING);
              String url = info.getURL().toDecodedString();
              String repoRoot = info.getRepositoryRootURL().toDecodedString();
              return new PathContext(url, repoRoot, null);
          } catch (SVNException e) {
              e.printStackTrace();
              return null;
          }
          

          So it can return null in case an SVNException has happend, in which case the exception is printed to stderr. This seems wrong practice to me.
          On the Log of the slave I see this error:

          org.tmatesoft.svn.core.SVNException: svn: E155007: '/opt/jenkins/c:\wsput\silent-installer' is not a working copy
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1938)
          	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1829)
          	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readConflicts(SVNWCDb.java:3360)
          	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readConflicts(SVNWCDb.java:3333)
          	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.opReadTreeConflict(SVNWCDb.java:2775)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetInfo.run(SvnNgGetInfo.java:72)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetInfo.run(SvnNgGetInfo.java:51)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
          	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
          	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
          	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          	at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2485)
          	at hudson.scm.SubversionChangeLogBuilder$GetContextForPath.invoke(SubversionChangeLogBuilder.java:253)
          	at hudson.scm.SubversionChangeLogBuilder$GetContextForPath.invoke(SubversionChangeLogBuilder.java:239)
          	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688)
          	at hudson.remoting.UserRequest.perform(UserRequest.java:121)
          	at hudson.remoting.UserRequest.perform(UserRequest.java:49)
          	at hudson.remoting.Request$2.run(Request.java:326)
          	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          	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:619)
          

          In my opinion the scope for this bug is fixing the NullPointerException, not the SVNException.

          Gerwin Jansen added a comment - I'm facing the same issue in 1.609.3 with SVN plugin 2.5.3. The NullPointerException is comming from line 122 (context = null): hudson.scm.SubversionChangeLogBuilder PathContext context = getUrlForPath(workspace.child(l.getLocalDir()), authProvider); context.moduleWorkspacePath = l.getLocalDir(); Apparently getUrlForPath returns null. The implementation is: hudson.scm.SubversionChangeLogBuilder return path.act( new GetContextForPath(authProvider)); So GetContextForPath callable returns null. The implementation is: hudson.scm.SubversionChangeLogBuilder try { info = svnwc.doInfo(p, SVNRevision.WORKING); String url = info.getURL().toDecodedString(); String repoRoot = info.getRepositoryRootURL().toDecodedString(); return new PathContext(url, repoRoot, null ); } catch (SVNException e) { e.printStackTrace(); return null ; } So it can return null in case an SVNException has happend, in which case the exception is printed to stderr. This seems wrong practice to me. On the Log of the slave I see this error: org.tmatesoft.svn.core.SVNException: svn: E155007: '/opt/jenkins/c:\wsput\silent-installer' is not a working copy at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1938) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1829) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readConflicts(SVNWCDb.java:3360) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readConflicts(SVNWCDb.java:3333) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.opReadTreeConflict(SVNWCDb.java:2775) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetInfo.run(SvnNgGetInfo.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetInfo.run(SvnNgGetInfo.java:51) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2485) at hudson.scm.SubversionChangeLogBuilder$GetContextForPath.invoke(SubversionChangeLogBuilder.java:253) at hudson.scm.SubversionChangeLogBuilder$GetContextForPath.invoke(SubversionChangeLogBuilder.java:239) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) 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:619) In my opinion the scope for this bug is fixing the NullPointerException, not the SVNException.

          gjansen Could you provide a step by step process to reproduce the bug?

          Manuel Recena Soto added a comment - gjansen Could you provide a step by step process to reproduce the bug?

          gjansen Anyway, I recommend you to upgrade to 2.5.7.

          Manuel Recena Soto added a comment - gjansen Anyway, I recommend you to upgrade to 2.5.7 .

          Alex Earl added a comment -

          Was this ever resolved? The path in the log of the agent looks wrong, you have mixed UNIX and Windows paths 
          /opt/jenkins/c:\wsput\silent-installer

          Alex Earl added a comment - Was this ever resolved? The path in the log of the agent looks wrong, you have mixed UNIX and Windows paths  /opt/jenkins/c:\wsput\silent-installer

            Unassigned Unassigned
            dimagr dima grinberg
            Votes:
            5 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: