Bugzilla – Full Text Bug Listing
| Summary: | [ui] checking for updates can block UI thread if resolution fails | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Steffen Pingel <steffen.pingel> |
| Component: | p2 | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | irbull, pascal, stephan.herrmann |
| Version: | 3.6 | ||
| Target Milestone: | 3.6 M7 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Are there any workarounds? I'm constantly getting this, and in my setup I seem to have no other choice than going through an explanation page, making changes and proceed. (This is caused by another weirdness: --All Available Sites-- does not show latest versions from one site, while selecting only this site does). (In reply to comment #1) > Are there any workarounds? Not really, I'm sorry. This bug has been around for awhile (I believe it is a variant of bug 290858) and I've simply been consumed with API freeze (and now eclipsecon). Sorry... If you enable automatic updates, the resolution occurs in a background job, so this might be one way to work around it... I suspect the time is really being spent in loading those repositories rather than in the resolution/error computation, so another way to work around is to disable repositories that you don't need. > > I'm constantly getting this, and in my setup I seem to have no > other choice than going through an explanation page, making changes > and proceed. > (This is caused by another weirdness: --All Available Sites-- > does not show latest versions from one site, while selecting only > this site does). Can you open a bug with repeatable steps - naming the sites in question and the versions not showing? Sounds like a possible bug in the query we are running. Fixed in HEAD >20100414. The fix for bug 290858 ensured that the search for updates (and repository loading that is triggered by this) occurs during the resolution phase of the update operation. Prior to this fix, the search was performed in-thread prior to creating the resolution job. This fix was a slightly different problem. The update handler was loading repositories in a background job and then resolving the operation modally. The assumption was that the repo loading was the expensive part and that resolution could safely happen in-thread. The fix is to add a hook for extra post-load processing that happens in the load job. The update handler does the resolution here. All that said, the fact that it took over 10 minutes to compute a failed resolution explanation is worrisome. Pascal, does this require further investigation (a new bug) or are you confident that changes in SAT4J have addressed that part of the problem? |
I have the Helios update site enabled which expectedly causes updates to fail for me due to conflicting versions. The problem is that once P2 blocks the UI thread for several minutes while trying to compute the error message without providing means to cancel (see below). In this particular case it did not come back for over 10 minutes so I had to terminate Eclipse forcefully. Version: 3.6.0 Build id: I20100312-1448 "main" prio=10 tid=0x09b6f000 nid=0x4fe9 in Object.wait() [0xbfea2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.eclipse.equinox.internal.p2.director.Projector.getExplanation(Projector.java:919) - locked <0x77e699e0> (a org.eclipse.equinox.internal.p2.director.Projector$ExplanationJob) at org.eclipse.equinox.internal.p2.director.SimplePlanner.getSolutionFor(SimplePlanner.java:320) at org.eclipse.equinox.internal.p2.director.SimplePlanner.getProvisioningPlan(SimplePlanner.java:351) at org.eclipse.equinox.internal.p2.operations.PlannerResolutionJob.runModal(PlannerResolutionJob.java:67) at org.eclipse.equinox.p2.operations.ProfileChangeOperation.resolveModal(ProfileChangeOperation.java:115) at org.eclipse.equinox.internal.p2.ui.sdk.UpdateHandler.doExecute(UpdateHandler.java:39) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.run(PreloadingRepositoryHandler.java:57) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) - locked <0x77900c00> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3507) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3154) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2416) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2380) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2229) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:504) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:497) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1406) "Worker-262" prio=10 tid=0xaccd4800 nid=0x2602 sleeping[0xa917b000] java.lang.Thread.State: RUNNABLE at org.sat4j.minisat.core.Heap.percolateDown(Unknown Source) at org.sat4j.minisat.core.Heap.getmin(Unknown Source) at org.sat4j.minisat.orders.VarOrderHeap.select(Unknown Source) at org.sat4j.minisat.core.Solver.search(Unknown Source) at org.sat4j.minisat.core.Solver.isSatisfiable(Unknown Source) at org.sat4j.tools.SolverDecorator.isSatisfiable(Unknown Source) at org.sat4j.pb.PseudoOptDecorator.admitABetterSolution(Unknown Source) at org.sat4j.pb.OptToPBSATAdapter.isSatisfiable(Unknown Source) at org.sat4j.tools.xplain.QuickXplainStrategy.computeExplanation(Unknown Source) at org.sat4j.tools.xplain.QuickXplainStrategy.explain(Unknown Source) at org.sat4j.tools.xplain.Xplain.explain(Unknown Source) at org.sat4j.pb.tools.DependencyHelper.why(Unknown Source) at org.eclipse.equinox.internal.p2.director.Projector$ExplanationJob.run(Projector.java:105) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)