Community
Participate
Working Groups
Build Identifier: 316636 I ran the eclipse-automation tests(3.4.2) in solaris-sparc10, this test fails with jdk7-b96, but it is fine with jdk6u20, not sure it is a eclipse bug or jdk bug. I filed a bug 316636, and I was asked by the evaluator to file one test by one bug, so I am filing bugs now: see exceptions below: Unexpected error output for invocation with arguments ["/comptest/run.1275906640378/regression/p/X.java" -1.5 -g -preserveAllLocals -d "/comptest/run.1275906640378/regression/out"]. ----------- Expected ------------ No .class file created for file p/X.class in ---OUTPUT_DIR_PLACEHOLDER---/out because of an IOException: Could not create subdirectory p into output directory ---OUTPUT_DIR_PLACEHOLDER---/out\n ------------ but was ------------ --------- Difference is ---------- expected:<[No .class file created for file p/X.class in ---OUTPUT_DIR_PLACEHOLDER---/out because of an IOException: Could not create subdirectory p into output directory ---OUTPUT_DIR_PLACEHOLDER---/out\n ]> but was:<[]> junit.framework.ComparisonFailure: Unexpected error output for invocation with arguments ["/comptest/run.1275906640378/regression/p/X.java" -1.5 -g -preserveAllLocals -d "/comptest/run.1275906640378/regression/out"]. ----------- Expected ------------ No .class file created for file p/X.class in ---OUTPUT_DIR_PLACEHOLDER---/out because of an IOException: Could not create subdirectory p into output directory ---OUTPUT_DIR_PLACEHOLDER---/out\n ------------ but was ------------ --------- Difference is ---------- expected:<[No .class file created for file p/X.class in ---OUTPUT_DIR_PLACEHOLDER---/out because of an IOException: Could not create subdirectory p into output directory ---OUTPUT_DIR_PLACEHOLDER---/out\n ]> but was:<[]> at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertStringEquals(TestCase.java:230) at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertEquals(TestCase.java:206) at org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest.runTest(BatchCompilerTest.java:592) at org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest.runConformTest(BatchCompilerTest.java:392) at org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest.test055(BatchCompilerTest.java:3833) at org.eclipse.jdt.core.tests.util.CompilerTestSetup.run(CompilerTestSetup.java:55) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:354) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:206) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:35) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:31) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) Reproducible: Always Steps to Reproduce: 1.Install jdk7-b96 2.Download eclipse-automation tests 3.4.2 3.run the tests in solaris-sparc10, you will find these three tests are failed with jdk7.
Moving to JDT Core
(In reply to comment #0) > Build Identifier: 316636 > > I ran the eclipse-automation tests(3.4.2) in solaris-sparc10, this test fails > with jdk7-b96, but it is fine with jdk6u20, not sure it is a eclipse bug or jdk > bug. test055 was introduced in bug 141522 and looks specific to some file systems such as that in Windows. I'm not sure if it applies to solaris too. The comment in the tests says "// read-only directories do not prevent file creation // on under-gifted file systems" Maybe the file system in solaris doesnt come under this category, and hence test055 should be switched off for Solaris. Olivier, what do you think?
(In reply to comment #2) Still I'm not sure why it passes with jdk6 and fails with 7!
(In reply to comment #2) > Maybe the file system in solaris doesnt come under this category, and hence > test055 should be switched off for Solaris. Olivier, what do you think? We don't have a solaris machine to test this. I would simply make sure that this test only runs on Windows if this is what was intended. This won't be backported to 3.4.x. The fix would only be released into HEAD.
Created attachment 177851 [details] proposed patch Srikanth, please review. TIA
Created attachment 177852 [details] proposed patch 2 Oops, the above patch contained some noise changes due to autosave.
Ayush, it makes no sense to limit this test to windows. Windows does allow you to create a file in a read only directory - it is the unix variants that don't allow. In fact this test written in such a way as to *skip* windows run. The entire test is bracketed by if (File.separatorChar == '/') { // test here } Since the separatorChar is \ on windows, the test doesn't run on windows today. There is some mystery here as to why the test would fail on Solaris with only JDK7. If we are unable to go after it ourselves perhaps we should tag it as help wanted.
(In reply to comment #2) > (In reply to comment #0) > > Build Identifier: 316636 > test055 was introduced in bug 141522 and looks specific to some file systems > such as that in Windows. I'm not sure if it applies to solaris too. The comment > in the tests says > "// read-only directories do not prevent file creation > // on under-gifted file systems" We want to skip the tests if this condition holds - i.e Windows. > Maybe the file system in solaris doesnt come under this category, Solaris (and none of the unix systems) will not allow file creation in a read only directory.
If this test doesn't run on Solaris, you should simply skip it on this platform. Ayushman, please follow up for M3.
Please release the patch and let someone with Solaris access to test it.
Created attachment 179559 [details] proposed patch 3 I intend to release this patch as per Olivier's comments above. Srikanth, let me know if you have any concerns about this. Thanks
(In reply to comment #9) > If this test doesn't run on Solaris, you should simply skip it on this > platform. This test is NOT supposed to NOT run on Solaris. Skipping this tests simply masks the problem. IMO, we are better off leaving it as it is than closing it by skiiping it for Solaris. (In reply to comment #11) > I intend to release this patch as per Olivier's comments above. Srikanth, let > me know if you have any concerns about this. Thanks Sight unseen, I would say the smoking gun points to JDK7. Tao, are you in a position to test with the latest JDK7 ?
The test checks if files or folders can be created in a read-only folder. This is OS dependent. For example, this is possible on Windows. I don't know Solaris, but if this is also possible on Solaris, then this test doesn't apply to Solaris and should be disabled.
Ok, I checked. Solaris doesn't let you write into a readonly folder. So this would be a bug in the JDK. Please try with a different JDK (1.6 for example). Closing as NOT_ECLIPSE.
Verified for 3.7M3.
