Bugzilla – Full Text Bug Listing
| Summary: | fix Gerrit Synchronization Test | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Miles Parker <milesparker> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sebastien.dubois, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Miles Parker
Here is the full stack trace: Thread[main,6,main] org.eclipse.swt.internal.gtk.OS._gtk_dialog_run(Native Method) org.eclipse.swt.internal.gtk.OS.gtk_dialog_run(OS.java:6591) org.eclipse.swt.widgets.MessageBox.open(MessageBox.java:189) org.eclipse.swt.browser.PromptService2.Alert(PromptService2.java:198) org.eclipse.swt.browser.PromptService2$3.method3(PromptService2.java:71) org.eclipse.swt.internal.mozilla.XPCOMObject.callback3(XPCOMObject.java:266) org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2276) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3207) org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.runEventLoop(EventLoopProgressMonitor.java:123) org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.isCanceled(EventLoopProgressMonitor.java:97) org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:921) org.eclipse.mylyn.gerrit.tests.core.GerritSynchronizationTest.synchronizeAllTasks(GerritSynchronizationTest.java:172) org.eclipse.mylyn.gerrit.tests.core.GerritSynchronizationTest.createAndSynchronizeQuery(GerritSynchronizationTest.java:158) org.eclipse.mylyn.gerrit.tests.core.GerritSynchronizationTest.testSynchronizeQueryNewTask(GerritSynchronizationTest.java:106) It looks like a test opened an internal browser that prompts for credentials and this is blocking the UI thread. Hmmm.. don't know what's happening here then ... the test occurs before any of the new/changed tests even run, and it happens on multiple changes against master, which didn't fail, though there was an issue with first an unexpected user name (I fixed that on test server) and then with a timeout set too low. I'm going to bump that timeout value up and trigger a new test. This is not related to the timeout. One of the tests is opening a browser that's blocking the test. These failures happened sporadically before but no one cared to look into it. (In reply to comment #3) > This is not related to the timeout. One of the tests is opening a browser that's > blocking the test. These failures happened sporadically before but no one cared > to look into it. Yeah, that's what I'm saying -- they're unrelated. :) I don't know anything about this issue -- is there a bug open for it? -- nor why it has suddenly picked today to start barfing. I've seen the test running locally and was wondering what was going on there. If you have an idea of a relatively simple test, I can take a look, but have really limited time. I hate to suggest this, but can we just kill the test for now? It's blocking us being able to confirm a lot of stuff that does need to be exercised -- like bug 405138. (In reply to comment #4) > Yeah, that's what I'm saying -- they're unrelated. :) I don't know anything > about this issue -- is there a bug open for it? Yes, this bug :). > I hate to suggest this, but can we just kill the test for now? Well, that's part of the problem we have to figure out which test is opening the browser. The test hangs because it spins the UI thread not because it opened the browser necessarily. So, no :). (In reply to comment #5) > Yes, this bug :). You mean this one that I just created? ;P > Well, that's part of the problem we have to figure out which test is opening the > browser. The test hangs because it spins the UI thread not because it opened the > browser necessarily. So, no :). Ok I have a working hypothesis. I note that this started just after I started spamming the Gerrit host with lot's of newly created reviews. I note that the synchornization test now takes a long time even on my local machine; like 90 seconds. Thinking maybe we'll want to synchronize against a more limited query or something. Investigating.. I think what is happening is that GerritUrlHandlerTest opens a browser for https://git.eclipse.org/r which has a certificate that is not recognized by Mozilla which causes the modal dialog to pop up. Here is a fix: https://git.eclipse.org/r/#/c/12257/.. I'm looking at speeding up tests. (In reply to comment #7) > I think what is happening is that GerritUrlHandlerTest opens a browser for > https://git.eclipse.org/r which has a certificate that is not recognized by > Mozilla which causes the modal dialog to pop up. Here is a fix: > https://git.eclipse.org/r/#/c/12257/.. Great, taking a look now. > > I'm looking at speeding up tests. Beat you to it: This one just searches for the first review. (And should fix bug 405138) https://git.eclipse.org/r/#/c/12258/ The fix was committed. Turns out there is another problem that causes a synchronization job to be re-scheduled all the time which frequently causes the Gerrit tests to still fail: https://git.eclipse.org/r/#/c/12491/. |