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

"java.io.IOException: Failed to clean up temp dirs" because of "secret.key"

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Windows 7 64bit
      java version "1.7.0_51"

      When testing my plugin by running mvn clean test, my own tests all pass successfully. However, the cleanup for the injected ones fails:

      org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest)  Time elapsed: 0.006 sec  <<< ERROR!
      java.io.IOException: Failed to clean up temp dirs
              at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:86)
              at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
              at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
              at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
              at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
              at junit.framework.TestSuite.runTest(TestSuite.java:255)
              at junit.framework.TestSuite.run(TestSuite.java:250)
              at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
              at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
              at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
              at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
              at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
              at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
              at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
      Caused by: java.nio.file.FileSystemException: C:\Users\simon\AppData\Local\Temp\hudson495525951667628343test\secret.key: The process cannot access the file bec
      ause it is being used by another process.
      
              at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
              at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
              at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
              at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
              at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
              at java.nio.file.Files.delete(Files.java:1077)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:606)
              at hudson.Util.deleteFile(Util.java:238)
              at hudson.Util.deleteRecursive(Util.java:301)
              at hudson.Util.deleteContentsRecursive(Util.java:203)
              at hudson.Util.deleteRecursive(Util.java:292)
              at hudson.FilePath$12.invoke(FilePath.java:1079)
              at hudson.FilePath$12.invoke(FilePath.java:1076)
              at hudson.FilePath.act(FilePath.java:914)
              at hudson.FilePath.act(FilePath.java:887)
              at hudson.FilePath.deleteRecursive(FilePath.java:1076)
              at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:81)
              at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
              at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
              at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
              at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
              at junit.framework.TestSuite.runTest(TestSuite.java:255)
              at junit.framework.TestSuite.run(TestSuite.java:250)
              at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
              at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
              at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
              at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
              at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
              at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
              at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
      

      So apparently something locks the "secret.key" file. And indeed, running the file leak detector, one can observe the following:

      Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
      st) on Thu Feb 27 12:06:13 CET 2014
      Closed C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
      st) on Thu Feb 27 12:06:13 CET 2014
      Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
      

      The secret.key file is opened, but not closed again. Full stacktrace for that is:

      Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
      	at java.io.FileInputStream.<init>(Unknown Source)
      	at jenkins.diagnosis.HsErrPidList.<init>(HsErrPidList.java:47)
      	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
      	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
      	at java.lang.reflect.Constructor.newInstance(Unknown Source)
      	at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
      	at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108)
      	at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:88)
      	at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:269)
      	at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
      	at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1058)
      	at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
      	at com.google.inject.Scopes$1$1.get(Scopes.java:65)
      	at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:429)
      	at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
      	at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:1005)
      	at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1051)
      	at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:1001)
      	at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:391)
      	at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:382)
      	at hudson.ExtensionFinder._find(ExtensionFinder.java:151)
      	at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:317)
      	at hudson.ExtensionList.load(ExtensionList.java:295)
      	at hudson.ExtensionList.ensureLoaded(ExtensionList.java:248)
      	at hudson.ExtensionList.iterator(ExtensionList.java:138)
      	at hudson.ExtensionList.get(ExtensionList.java:129)
      	at hudson.diagnosis.NullIdDescriptorMonitor.verifyId(NullIdDescriptorMonitor.java:86)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105)
      	at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:169)
      	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
      	at jenkins.model.Jenkins$7.runTask(Jenkins.java:900)
      	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
      	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      	at java.lang.Thread.run(Unknown Source)
      
      

      Evidently, HsErrPidList is the culprit here. And indeed, it intentionally keeps this file handle open as a marker:

          /**
           * Used to keep a marker file memory-mapped, so that we can find hs_err_pid files that belong to us.
           */
          private MappedByteBuffer map;
      
          public HsErrPidList() {
              try {
                  FileChannel ch = new FileInputStream(getSecretKeyFile()).getChannel();
                  map = ch.map(MapMode.READ_ONLY,0,1);
      

      While this might be a quite convenient trick orignially, it is quite a nuisance when trying to run integration tests. I have observed that only on Windows so far - it does not happen to me on proper operation systems. Unfortunately, I'm stuck with Windows in my current project.

      Any ideas? Fixes or suggestions for workarounds are highly appreciated!

          [JENKINS-21977] "java.io.IOException: Failed to clean up temp dirs" because of "secret.key"

          Simon Kaufmann created issue -
          Simon Kaufmann made changes -
          Description Original: When testing my plugin by running {{mvn clean test}}, my own tests all pass successfully. However, the cleanup for the injected ones fails:

          {code}
          org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest) Time elapsed: 0.006 sec <<< ERROR!
          java.io.IOException: Failed to clean up temp dirs
                  at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:86)
                  at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
                  at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
                  at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
                  at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
                  at junit.framework.TestSuite.runTest(TestSuite.java:255)
                  at junit.framework.TestSuite.run(TestSuite.java:250)
                  at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
                  at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
                  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
                  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
          Caused by: java.nio.file.FileSystemException: C:\Users\simon\AppData\Local\Temp\hudson495525951667628343test\secret.key: The process cannot access the file bec
          ause it is being used by another process.

                  at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
                  at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
                  at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
                  at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
                  at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
                  at java.nio.file.Files.delete(Files.java:1077)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                  at java.lang.reflect.Method.invoke(Method.java:606)
                  at hudson.Util.deleteFile(Util.java:238)
                  at hudson.Util.deleteRecursive(Util.java:301)
                  at hudson.Util.deleteContentsRecursive(Util.java:203)
                  at hudson.Util.deleteRecursive(Util.java:292)
                  at hudson.FilePath$12.invoke(FilePath.java:1079)
                  at hudson.FilePath$12.invoke(FilePath.java:1076)
                  at hudson.FilePath.act(FilePath.java:914)
                  at hudson.FilePath.act(FilePath.java:887)
                  at hudson.FilePath.deleteRecursive(FilePath.java:1076)
                  at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:81)
                  at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
                  at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
                  at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
                  at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
                  at junit.framework.TestSuite.runTest(TestSuite.java:255)
                  at junit.framework.TestSuite.run(TestSuite.java:250)
                  at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
                  at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
                  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
                  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
          {code}

          So apparently something locks the "secret.key" file. And indeed, running the file leak detector, one can observe the following:

          {code}
          Opened C:\Users\kai7si\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
          st) on Thu Feb 27 12:06:13 CET 2014
          Closed C:\Users\kai7si\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
          st) on Thu Feb 27 12:06:13 CET 2014
          Opened C:\Users\kai7si\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
          {code}

          The secret.key file is opened, but not closed again. Full stacktrace for that is:

          {code}
          Opened C:\Users\kai7si\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
          at java.io.FileInputStream.<init>(Unknown Source)
          at jenkins.diagnosis.HsErrPidList.<init>(HsErrPidList.java:47)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
          at java.lang.reflect.Constructor.newInstance(Unknown Source)
          at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
          at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108)
          at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:88)
          at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:269)
          at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
          at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1058)
          at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
          at com.google.inject.Scopes$1$1.get(Scopes.java:65)
          at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:429)
          at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
          at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:1005)
          at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1051)
          at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:1001)
          at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:391)
          at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:382)
          at hudson.ExtensionFinder._find(ExtensionFinder.java:151)
          at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:317)
          at hudson.ExtensionList.load(ExtensionList.java:295)
          at hudson.ExtensionList.ensureLoaded(ExtensionList.java:248)
          at hudson.ExtensionList.iterator(ExtensionList.java:138)
          at hudson.ExtensionList.get(ExtensionList.java:129)
          at hudson.diagnosis.NullIdDescriptorMonitor.verifyId(NullIdDescriptorMonitor.java:86)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at java.lang.reflect.Method.invoke(Unknown Source)
          at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105)
          at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:169)
          at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
          at jenkins.model.Jenkins$7.runTask(Jenkins.java:900)
          at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
          at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

          {code}

          Evidently, {{HsErrPidList}} is the culprit here. And indeed, it _intentionally_ keeps this file handle open as a marker:

          {code}
              /**
               * Used to keep a marker file memory-mapped, so that we can find hs_err_pid files that belong to us.
               */
              private MappedByteBuffer map;

              public HsErrPidList() {
                  try {
                      FileChannel ch = new FileInputStream(getSecretKeyFile()).getChannel();
                      map = ch.map(MapMode.READ_ONLY,0,1);
          {code}

          While this might be a quite convenient trick orignially, it is quite a nuisance when trying to run integration tests. I have observed that only on Windows so far - it does not happen to me on proper operation systems. Unfortunately, I'm stuck with Windows in my current project.

          Any ideas? Fixes or suggestions for workarounds are highly appreciated!
          New: When testing my plugin by running {{mvn clean test}}, my own tests all pass successfully. However, the cleanup for the injected ones fails:

          {code}
          org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite(org.jvnet.hudson.test.junit.FailedTest) Time elapsed: 0.006 sec <<< ERROR!
          java.io.IOException: Failed to clean up temp dirs
                  at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:86)
                  at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
                  at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
                  at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
                  at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
                  at junit.framework.TestSuite.runTest(TestSuite.java:255)
                  at junit.framework.TestSuite.run(TestSuite.java:250)
                  at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
                  at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
                  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
                  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
          Caused by: java.nio.file.FileSystemException: C:\Users\simon\AppData\Local\Temp\hudson495525951667628343test\secret.key: The process cannot access the file bec
          ause it is being used by another process.

                  at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
                  at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
                  at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
                  at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
                  at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
                  at java.nio.file.Files.delete(Files.java:1077)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                  at java.lang.reflect.Method.invoke(Method.java:606)
                  at hudson.Util.deleteFile(Util.java:238)
                  at hudson.Util.deleteRecursive(Util.java:301)
                  at hudson.Util.deleteContentsRecursive(Util.java:203)
                  at hudson.Util.deleteRecursive(Util.java:292)
                  at hudson.FilePath$12.invoke(FilePath.java:1079)
                  at hudson.FilePath$12.invoke(FilePath.java:1076)
                  at hudson.FilePath.act(FilePath.java:914)
                  at hudson.FilePath.act(FilePath.java:887)
                  at hudson.FilePath.deleteRecursive(FilePath.java:1076)
                  at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:81)
                  at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:81)
                  at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:414)
                  at org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite.tearDown(JellyTestSuiteBuilder.java:138)
                  at org.jvnet.hudson.test.junit.GroupedTest.run(GroupedTest.java:53)
                  at junit.framework.TestSuite.runTest(TestSuite.java:255)
                  at junit.framework.TestSuite.run(TestSuite.java:250)
                  at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
                  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
                  at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
                  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
                  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
          {code}

          So apparently something locks the "secret.key" file. And indeed, running the file leak detector, one can observe the following:

          {code}
          Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
          st) on Thu Feb 27 12:06:13 CET 2014
          Closed C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key.not-so-secret by thread:Executing smokeTest(com.bosch.cdg.jenkins.bfw.SmokeTe
          st) on Thu Feb 27 12:06:13 CET 2014
          Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
          {code}

          The secret.key file is opened, but not closed again. Full stacktrace for that is:

          {code}
          Opened C:\Users\simon\AppData\Local\Temp\hudson8963470585336900037test\secret.key by thread:NullIdDescriptorMonitor.verifyId on Thu Feb 27 12:06:26 CET 2014
          at java.io.FileInputStream.<init>(Unknown Source)
          at jenkins.diagnosis.HsErrPidList.<init>(HsErrPidList.java:47)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
          at java.lang.reflect.Constructor.newInstance(Unknown Source)
          at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
          at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108)
          at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:88)
          at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:269)
          at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
          at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1058)
          at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
          at com.google.inject.Scopes$1$1.get(Scopes.java:65)
          at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:429)
          at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
          at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:1005)
          at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1051)
          at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:1001)
          at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:391)
          at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:382)
          at hudson.ExtensionFinder._find(ExtensionFinder.java:151)
          at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:317)
          at hudson.ExtensionList.load(ExtensionList.java:295)
          at hudson.ExtensionList.ensureLoaded(ExtensionList.java:248)
          at hudson.ExtensionList.iterator(ExtensionList.java:138)
          at hudson.ExtensionList.get(ExtensionList.java:129)
          at hudson.diagnosis.NullIdDescriptorMonitor.verifyId(NullIdDescriptorMonitor.java:86)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at java.lang.reflect.Method.invoke(Unknown Source)
          at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105)
          at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:169)
          at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
          at jenkins.model.Jenkins$7.runTask(Jenkins.java:900)
          at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
          at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

          {code}

          Evidently, {{HsErrPidList}} is the culprit here. And indeed, it _intentionally_ keeps this file handle open as a marker:

          {code}
              /**
               * Used to keep a marker file memory-mapped, so that we can find hs_err_pid files that belong to us.
               */
              private MappedByteBuffer map;

              public HsErrPidList() {
                  try {
                      FileChannel ch = new FileInputStream(getSecretKeyFile()).getChannel();
                      map = ch.map(MapMode.READ_ONLY,0,1);
          {code}

          While this might be a quite convenient trick orignially, it is quite a nuisance when trying to run integration tests. I have observed that only on Windows so far - it does not happen to me on proper operation systems. Unfortunately, I'm stuck with Windows in my current project.

          Any ideas? Fixes or suggestions for workarounds are highly appreciated!

          Jacob Schoen added a comment -

          I am not sure how much value this adds to the discussion, but changing the version of the parent pom to 1.539 does resolve the issue with compiling, at least as a temporary solution for now. Changing it to anything higher than that causes it to break again. Which seems reasonable as that was when [HsErrPidList](https://github.com/jenkinsci/jenkins/commit/7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be#diff-25fdfbd4ba585cae537640edef6b67a9) was added in.

          Jacob Schoen added a comment - I am not sure how much value this adds to the discussion, but changing the version of the parent pom to 1.539 does resolve the issue with compiling, at least as a temporary solution for now. Changing it to anything higher than that causes it to break again. Which seems reasonable as that was when [HsErrPidList] ( https://github.com/jenkinsci/jenkins/commit/7d2a3b3f9c96f3ab950d84781da5cf903ca4c4be#diff-25fdfbd4ba585cae537640edef6b67a9 ) was added in.

          Mark Waite added a comment -

          I see the same condition still on 1.554.1. It makes Windows based development more painful, since there are now test failures which I must remember to ignore.

          Mark Waite added a comment - I see the same condition still on 1.554.1. It makes Windows based development more painful, since there are now test failures which I must remember to ignore.

          Jesse Glick added a comment -

          This code should simply be disabled when Functions.getIsUnitTest().

          Jesse Glick added a comment - This code should simply be disabled when Functions.getIsUnitTest() .

          Dony added a comment - - edited

          I also encountered this issue when I was trying to run integration tests about workflow plugin on Windows.

          Dony added a comment - - edited I also encountered this issue when I was trying to run integration tests about workflow plugin on Windows.
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Jesse Glick made changes -
          Labels New: lts-candidate test

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/java/jenkins/diagnosis/HsErrPidList.java
          http://jenkins-ci.org/commit/jenkins/f39c435f8c86403653dc777516a4853e912044e3
          Log:
          [FIXED JENKINS-21977] Skip HsErrPidList when running functional tests.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/jenkins/diagnosis/HsErrPidList.java http://jenkins-ci.org/commit/jenkins/f39c435f8c86403653dc777516a4853e912044e3 Log: [FIXED JENKINS-21977] Skip HsErrPidList when running functional tests.

            jglick Jesse Glick
            sjka Simon Kaufmann
            Votes:
            10 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: