Community
Participate
Working Groups
Consistently 15 tests are failing on Mac 10.13.5 in TestCase LeakTestSuite. http://download.eclipse.org/eclipse/downloads/drops4/I20180801-2000/testresults/html/org.eclipse.jdt.ui.tests_ep49I-unit-mac64_macosx.cocoa.x86_64_8.0.html
Kalyan, any progress?
(In reply to Dani Megert from comment #1) > Kalyan, any progress? I have not been able to reproduce these test failures locally on Mac.
(In reply to Kalyan Prasad Tatavarthi from comment #2) > (In reply to Dani Megert from comment #1) > > Kalyan, any progress? > > I have not been able to reproduce these test failures locally on Mac. I assume you used Mac 10.13.5 with JRE 8? Did you check the log files? Ask Sravan whether something is different on the Mac setup compared to what you use.
I have used Mac 10.13.6 with JRE 8 (172) but could not reproduce the test failure. The configuration is same as the test machine.
Any update here?
Kalyan are you still investigating this one?
(In reply to Dani Megert from comment #6) > Kalyan are you still investigating this one? I have not looked into this bug for past 2 weeks but will start looking into this bug this week.
(In reply to Kalyan Prasad Tatavarthi from comment #7) > (In reply to Dani Megert from comment #6) > > Kalyan are you still investigating this one? > > I have not looked into this bug for past 2 weeks but will start looking into > this bug this week. Ping!
Kalyan, have you tried interpreting the failure message? There seems to be a lot information contained, just it won't be easy to interpret. E.g.: Expected instance count: 0, actual: 1 Element 0 org.eclipse.jdt.internal.ui.propertiesfileeditor.PropertiesFileEditor org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate#fEditor -> org.eclipse.jdt.internal.ui.propertiesfileeditor.PropertiesFileEditor@1a407fbb org.eclipse.ui.internal.PluginAction#delegate -> org.eclipse.search2.internal.ui.text2.FindInFileActionDelegate@63e25a07 org.eclipse.jface.action.ActionContributionItem#action -> WWinPluginAction [id=org.eclipse.search.TextSearchFile, enabled=true, actionSet=org.eclipse.search. java.lang.Object[129] -> PluginActionContributionItem(id=org.eclipse.search.TextSearchFile, visible=true) org.eclipse.core.runtime.ListenerList#listeners -> [Ljava.lang.Object;@4ea5e22f org.eclipse.ui.internal.activities.AbstractActivityManager#activityManagerListeners -> [org.eclipse.ui.internal.ActivityPersistanceHelper$1@63b15742, PluginActionContributionItem(id=open org.eclipse.ui.internal.activities.ws.WorkbenchActivitySupport#proxyActivityManager -> org.eclipse.ui.internal.activities.ProxyActivityManager@67feb5d0 org.eclipse.ui.internal.Workbench#workbenchActivitySupport -> org.eclipse.ui.internal.activities.ws.WorkbenchActivitySupport@40c4b938 org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl#service -> org.eclipse.ui.internal.Workbench@77a35b2f java.lang.Object[200] -> {org.eclipse.ui.IWorkbench}={service.id=207, service.bundleid=252, service.scope=singleton, id=d57c java.util.ArrayList#elementData -> [Ljava.lang.Object;@6484364f org.eclipse.osgi.internal.serviceregistry.ServiceRegistry#allPublishedServices -> [{org.eclipse.osgi.framework.log.FrameworkLog}={service.id=4, service.bundleid=0, service.scope=bun org.eclipse.osgi.internal.framework.EquinoxContainer#serviceRegistry -> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry@1ec09a68 org.eclipse.osgi.internal.loader.BundleLoader#container -> Equinox Container: d8d477d0-e55d-4a31-aea5-ee2e5889ea84 org.eclipse.osgi.internal.loader.EquinoxClassLoader#delegate -> org.eclipse.jdt.ui.tests_3.13.400.v20190112-1750 org.eclipse.osgi.internal.loader.EquinoxClassLoader -> org.eclipse.osgi.internal.loader.EquinoxClassLoader@582e9152[org.eclipse.jdt.ui.tests:3.13.400.v201 If I understand correctly this should be the chain of back links, indicating the path from gc-root holding the leaked object. I.e., EquinoxClassLoader would be the gc-root and PropertiesFileEditor@1a407fbb would be the leaked object. From a quick glance, seeing FindInFileActionDelegate keeping an editor alive looks wrong. If these hints lead nowhere, should we let the suite take snapshots whenever a test fails? Perhaps some dialog prevents closing some editor or similar? Similar to what org.eclipse.test.TracingSuite does on timeout?
*** Bug 546583 has been marked as a duplicate of this bug. ***
Something is changed between I20190512-1800 and I20190510-1800! In I20190512-1800 we don't see LeakTestSuite failures anymore on Mac, but I don't see *any* possibly related change in the entire SDK that went between (I20190510-1800, I20190512-1800] tags range. https://download.eclipse.org/eclipse/downloads/drops4/I20190510-1800/testresults/html/org.eclipse.jdt.ui.tests_ep412I-unit-mac64-java8_macosx.cocoa.x86_64_8.0.html https://download.eclipse.org/eclipse/downloads/drops4/I20190512-1800/testresults/html/org.eclipse.jdt.ui.tests_ep412I-unit-mac64-java8_macosx.cocoa.x86_64_8.0.html
(In reply to Andrey Loskutov from comment #11) > Something is changed between I20190512-1800 and I20190510-1800! > > In I20190512-1800 we don't see LeakTestSuite failures anymore on Mac, but I > don't see *any* possibly related change in the entire SDK that went between > (I20190510-1800, I20190512-1800] tags range. > > https://download.eclipse.org/eclipse/downloads/drops4/I20190510-1800/ > testresults/html/org.eclipse.jdt.ui.tests_ep412I-unit-mac64-java8_macosx. > cocoa.x86_64_8.0.html > > https://download.eclipse.org/eclipse/downloads/drops4/I20190512-1800/ > testresults/html/org.eclipse.jdt.ui.tests_ep412I-unit-mac64-java8_macosx. > cocoa.x86_64_8.0.html We have not been able to figure out the reason for these tests to start passing. I have asked the question in https://bugs.eclipse.org/bugs/show_bug.cgi?id=540374#c10 and got the reply https://bugs.eclipse.org/bugs/show_bug.cgi?id=540374#c11. So closing this bug as tests pass on the Mac build machine in the nightly buiulds as well as for 4.12 M3 https://download.eclipse.org/eclipse/downloads/drops4/S-4.12M3-201905221800/testResults.php
