Community
Participate
Working Groups
This is a significant and disconcerting regression since F3. After upgrading to GM1 yesterday, we noticed that when we ran our complete suite of tests (about 380 test cases needing about 30 seconds), the cpu meter showed the system hard at work, but there was no output in the JUnit view. After about 30 seconds, cpu usage dropped off to near zero, at which point the JUnit progress indicator started moving and the numbers started flying. (Side note: This was in spite of the fact that the second processor was apparently not in significant use, at least according to the cpu meter.) We are using GM1/linux/gtk on a RH7.2 distro of linux on a 2GHz dual-processor pentium.
Have not seen the problem in GM4. Will keep you posted.
Okay, we have now seen the problem in GM4. It was after we had been running for some time. I'm wondering if it might have something to do with having both a Java and a Debug perspective which each have a JUnit view. Not sure, though.
Tried to reproduce this on Win with a JUnit view open in both the debug and java perspective, but I do not see this delay when running 400 test cases. When it happens the next time it would be helpful to attach a thread dump of Eclipse
Unsure if this is related but there are PRs saying that in GTK the UI doesn't repaint if the event loop is busy. Don't know if this is the case here. Eric, do you also see the problem under Windows ?
We continue to see this problem frequently, running R2.0, using gtk. I'm afraid all of our developers are using ecliplse/linux/gtk. I'm afraid I can't tell you the behavior under Windows. How can we supply you a thread dump?
Do the following: - start eclipse with the vm argument and provide a java.exe not a javaw.exe. I use D:\apps\eclipse\eclipse.exe -vm D:\jdk\bin\java.exe -vmargs -Xms30M - Xmx200M - you now get an additional console window (at least under windows, I hope the same happens under Linix/GTK). - if the problem appears simply press Ctrl+Break in the console. This prints the current thread dump to the console. Let me know if it works
See also bug 21382
Erich, do you know if you changed some operation execution to fork=false ?
Dirk, I had some side discussion with Eric on this problem by mail and the plan was that I send Eric an instrumented version of the plugin. However, your pointer to bug 21382 is good and can explain the problem. The problem can be reduced by processing the events the junit-ui receives from the test runner with syncExec instead of asyncExec. However, this is a change we are not comfortable with putting into 2.0.1 since it might result in dead locks. Eric, I've attached a plugin version that uses syncExec in the case you want to try it whether this fixes the problem.
Created attachment 1808 [details] patched org.eclipse.jdt.junit plugin
changed the code to syncExec in the 2.1 stream
