Community
Participate
Working Groups
Follow up from https://bugs.eclipse.org/bugs/show_bug.cgi?id=573547#c5
*** Bug 577186 has been marked as a duplicate of this bug. ***
I'm the author of Bug 575787. I tried to debug the test, but eventually I didn't manage to build. I to build from repo 'eclipse.platform.releng.aggregator', but didn't succeed. I also tried to use Eclipse SDK jars, also didnt' succeed. Are there ready-to-use jars for this project and its dependencies I could get to test?
(In reply to Alexandr Miloslavskiy from comment #2) > I'm the author of Bug 575787. I tried to debug the test, but eventually I > didn't manage to build. > > I to build from repo 'eclipse.platform.releng.aggregator', but didn't > succeed. > I also tried to use Eclipse SDK jars, also didnt' succeed. > > Are there ready-to-use jars for this project and its dependencies I could > get to test? You can use JDT Debug gerrit also, https://bugs.eclipse.org/bugs/show_bug.cgi?id=573547#c14 If you add the "triggerWinGerrit" message in commit, JDT debug gerrit will also run on Windows.
https://download.eclipse.org/eclipse/downloads/drops4/I20211110-1800/testresults/html/org.eclipse.jdt.debug.tests_ep422I-unit-win32-java11_win32.win32.x86_64_11.html
The problem was caused by a mistake in patch for Bug 575787. The patch is currently reverted, so tests should pass again. Sorry for the trouble!
Not seeing the failure, hope it's fixed indirectly.
Failing again these days https://download.eclipse.org/eclipse/downloads/drops4/I20220309-1800/testresults/html/org.eclipse.jdt.debug.tests_ep424I-unit-macM1-java17_macosx.cocoa.aarch64_17.html
There is a method called org.eclipse.jdt.debug.tests.ui.AbstractDebugUiTests.processUiEvents(long) which looks like it should run UI events for long number of milliseconds. However its current implementation does a "Thread.sleep()" and then clears all queued events (With org.eclipse.jdt.debug.tests.TestUtil.runEventLoop()) I have hit similar problems before that the eventloop can be empty more easily on some platforms than other. Instead I propose processUiEvents runs the event loop for the given number of milliseconds. On my local test making this change made the test pass when it used to fail. Gerrit coming soon with a triggerWinGerrit in the commit message.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/191731
(In reply to Eclipse Genie from comment #9) > New Gerrit change created: > https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/191731 Nope - that doesn't solve the issue.
What makes this test different from all the rest is that it selects a different frame as part of the test. Selecting a frame (via SourceDisplayJob) does a AbstractTextEditor.selectAndReveal on the new frame's location in the editor. A few lines later in the test the key AbstractTextEditor.selectAndReveal is done on the target of the test. The select a frame involves some complicated aysnc behaviour before the selectAndReveal and is scheduled on the UI thread, and this causes a race condition. You can see this by instrumenting StyledText.setSelection - it will be called twice (within key code) - once from SourceDisplayJob and once from the test. I will attempt to provide something to make the code wait properly on select frame - rather than just increase the amount of time we sleep.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/191738
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/191738 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e8f3ae035ee8c28629bff31abad7dcfc84292252
Tests have not failed in couple of days. Thank you Jonah!
