Details
-
Bug
-
Resolution: Fixed
-
Major
-
Windows 7 64bit
java version "1.7.0_51"
Description
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!
