Community
Participate
Working Groups
There were as many as 183 test failures in the last M build: http://download.eclipse.org/eclipse/downloads/drops4/M20151125-1000/testresults/html/org.eclipse.jdt.core.tests.compiler_linux.gtk.x86_64_8.0.html The failures have more or less have this stack: java.lang.NullPointerException at org.eclipse.jdt.core.tests.eval.JDIStackFrame.getDebuggedThread(JDIStackFrame.java:100) at org.eclipse.jdt.core.tests.eval.JDIStackFrame.<init>(JDIStackFrame.java:87) at org.eclipse.jdt.core.tests.eval.JDIStackFrame.<init>(JDIStackFrame.java:67) at org.eclipse.jdt.core.tests.eval.JDIStackFrame.<init>(JDIStackFrame.java:57) at org.eclipse.jdt.core.tests.eval.DebugEvaluationTest.testNegative005(DebugEvaluationTest.java:3070) This looks like there is a problem in accessing JDT through connector. This is all internal to JVM, so at this point I have no idea what's going on.
Has the build machine changed or were there some firewall rule / network related changes? From http://download.eclipse.org/eclipse/downloads/drops4/I20160314-2000/testresults/macosx.cocoa.x86_64_8.0/org.eclipse.jdt.core.tests.eval.TestAll.txt Could not contact the VM at localhost:64197. Retrying... Listening for transport dt_socket at address: 64197 Could not contact the VM at localhost:64202. Retrying... Could not contact the VM at localhost:64202. Retrying... Listening for transport dt_socket at address: 64202 Could not contact the VM at localhost:64208. Retrying... Could not contact the VM at localhost:64208. Retrying... Listening for transport dt_socket at address: 64208 Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Could not contact the VM at localhost:64215. Retrying... Listening for transport dt_socket at address: 64215 Could not contact the VM at localhost:64227. Retrying... Could not contact the VM at localhost:64227. Retrying... Listening for transport dt_socket at address: 64227 Could not contact the VM at localhost:64233. Retrying... Could not contact the VM at localhost:64233. Retrying... Listening for transport dt_socket at address: 64233
Failed again on Linux: http://download.eclipse.org/eclipse/downloads/drops4/I20160315-2000/testresults/html/org.eclipse.jdt.core.tests.compiler_linux.gtk.x86_64_8.0.html
(In reply to Andrey Loskutov from comment #1) There are similar logs but this time on Linux where the tests failed. Looks like even when there were no failures, we do end up retrying. The code retries 10 times and sets the timeout at 10000ms. And every retry is done after a 100ms delay. One option is to try a higher value for one/all of these.
(In reply to Jay Arthanareeswaran from comment #3) > (In reply to Andrey Loskutov from comment #1) > > There are similar logs but this time on Linux where the tests failed. Looks > like even when there were no failures, we do end up retrying. The code > retries 10 times and sets the timeout at 10000ms. And every retry is done > after a 100ms delay. One option is to try a higher value for one/all of > these. I wonder what changed that the delay need to be increased (if it will help at all)? The question (for webmasters) is: do we made recently some changes in the infrastructure? We observe this "timeout" failures only last few days.
Among the 183 failures, several tests are affected by a null EvaluationContext. To make it easier to find this bug in future, here is the stack trace that is attached to one of such: java.lang.NullPointerException at org.eclipse.jdt.core.tests.eval.SanityTestEvaluationContext.testEvaluate(SanityTestEvaluationContext.java:80) at org.eclipse.jdt.core.tests.util.CompilerTestSetup.run(CompilerTestSetup.java:56) Failures are spread across several test suites but they are essentially the same. Some of them from the list: SanityTestEvaluationContext.testEvaluate VariableTest.testAllKindOfValues EvaluationTest.evaluateWithExpectedDisplayString CodeSnippetTest.testEvaluateEmptyImport
Another observation: Looks like we faced similar issue in the past (bug 188127). The timeout was increased from 10000ms to 30000ms in EvaluationSetup#setUp(). The problem happening now is in DebugEvaluationSetup#setUp(), which is the overridden version of the former.
(In reply to Andrey Loskutov from comment #4) > The question (for webmasters) is: do we made recently some changes in the > infrastructure? We observe this "timeout" failures only last few days. There have been no recent hardware/software changes, but we have noticed that the load on the download server has increased over the last while, so that may be a factor. -M.
Seems to be related too: http://download.eclipse.org/eclipse/downloads/drops4/I20160316-0800/testresults/html/org.eclipse.ua.tests_linux.gtk.x86_64_8.0.html 110 errors with same stack: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at java.net.Socket.connect(Socket.java:538) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.<init>(HttpClient.java:211) at sun.net.www.http.HttpClient.New(HttpClient.java:308) at sun.net.www.http.HttpClient.New(HttpClient.java:326) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1168) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:932) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440) at java.net.URL.openStream(URL.java:1038) at org.eclipse.ua.tests.help.webapp.TocZipTest.readPage(TocZipTest.java:62) at org.eclipse.ua.tests.help.webapp.TocZipTest.testDocInZipOnly(TocZipTest.java:42
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
