Community
Participate
Working Groups
from https://download.eclipse.org/eclipse/downloads/drops4/I20200429-1800/testresults/html/org.eclipse.jdt.core.tests.builder_ep416I-unit-cen64-gtk3-java8_linux.gtk.x86_64_8.0.html Following tests failing: testLeaksOnFullBuild testLeaksOnCleanBuild testLeaksOnIncrementalBuild
Failed to read opened file descriptors junit.framework.AssertionFailedError: Failed to read opened file descriptors at junit.framework.Assert.fail(Assert.java:57) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertFalse(Assert.java:39) at junit.framework.TestCase.assertFalse(TestCase.java:208) at org.eclipse.jdt.core.tests.builder.AbstractLeakTest.checkOpenDescriptors(AbstractLeakTest.java:163) at org.eclipse.jdt.core.tests.builder.AbstractLeakTest.assertNotLeaked(AbstractLeakTest.java:137) at org.eclipse.jdt.core.tests.builder.AbstractLeakTest.internalTestUsedLibraryLeaks(AbstractLeakTest.java:89) at org.eclipse.jdt.core.tests.builder.AbstractLeakTest.testLeaksOnFullBuild(AbstractLeakTest.java:70) at org.eclipse.jdt.core.tests.builder.LeakTestsBefore9.testLeaksOnFullBuild(LeakTestsBefore9.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at junit.framework.TestCase.runTest(TestCase.java:177) at org.eclipse.jdt.core.tests.junit.extension.TestCase.runTest(TestCase.java:957) at junit.framework.TestCase.runBare(TestCase.java:142) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:130) at junit.framework.TestSuite.runTest(TestSuite.java:241) at junit.framework.TestSuite.run(TestSuite.java:236) at junit.framework.TestSuite.runTest(TestSuite.java:241) at junit.framework.TestSuite.run(TestSuite.java:236) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
I believe this is a duplicate. The problem is that after all the infrastructure changes "lsof" executable is not more installed or installed but in unusual place and not more in the path of the test instance.
And it is not only on Java 14, all Linux test instances are affected, see for example https://download.eclipse.org/eclipse/downloads/drops4/I20200513-1800/testresults/html/org.eclipse.jdt.core.tests.builder_ep416I-unit-cen64-gtk3-java8_linux.gtk.x86_64_8.0.html
See bug 561967 comment 2. Al that started with bug 561138. We have wrong PATH, we have wrong LANG.
(In reply to Andrey Loskutov from comment #4) > See bug 561967 comment 2. Al that started with bug 561138. > > We have wrong PATH, we have wrong LANG. @Andrey - Had an offline discussion with Sravan, updating the discussion points: - See https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/dockerfiles/centos-gtk3-metacity/7-gtk3/Dockerfile#n19 to find that lsof is added. - he also confirmed export LANG=en_US.UTF-8 is added as well. Don't want to have these discussions move in to this bug from bug 561967. Moving to 4.17 - to investigate further.
New Gerrit change created: https://git.eclipse.org/r/163322
Gerrit change https://git.eclipse.org/r/163322 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=8767458107de1a7d57e3c050b80cbc7196b54be7
I have an idea - could it be, the test instance workspace is on a network mount? If so, lsof check will avoid using that file system to avoid blocking kernel calls.
(In reply to Andrey Loskutov from comment #8) > I have an idea - could it be, the test instance workspace is on a network > mount? If so, lsof check will avoid using that file system to avoid blocking > kernel calls. No idea, Sravan might offer some insight there.
no we are not using network mounts.
Bulk move out of 4.17
Bulk move out of 4.19
Can we stop using lsof and make use of UnixOperatingSystemMXBean ? https://stackoverflow.com/questions/16360720/how-to-find-out-number-of-files-currently-open-by-java-application If we don't need to the kernel level descriptors.
(In reply to Gayan Perera from comment #13) > Can we stop using lsof and make use of UnixOperatingSystemMXBean ? > https://stackoverflow.com/questions/16360720/how-to-find-out-number-of-files- > currently-open-by-java-application > > If we don't need to the kernel level descriptors. Sure. Test if the numbers reported by lsof/other code match, add some production code that leaks descriptor and make sure the test fails, and after that push the test to gerrit :)
*** This bug has been marked as a duplicate of bug 571640 ***
