Bugzilla – Full Text Bug Listing
| Summary: | Workbench still locks up occasionally | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] Tigerstripe | Reporter: | Chris Hartley <chrhartl> | ||||||
| Component: | Core | Assignee: | Chris Hartley <chrhartl> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | blocker | ||||||||
| Priority: | P3 | CC: | erdillon | ||||||
| Version: | 0.5M1 | ||||||||
| Target Milestone: | 0.5M0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Chris Hartley
The latest version (just updated) of TS has locked up twice today - when adding associations I re-ran with the Java monitor and it finds no deadlocks. I've done a dump with jstack (attached) Name: main State: BLOCKED on java.lang.Object@a70183 owned by: Worker-0 Total blocked: 588 Total waited: 656 Stack trace: org.eclipse.core.commands.operations.DefaultOperationHistory.getUndoOperation(DefaultOperationHistory.java:854) org.eclipse.core.commands.operations.DefaultOperationHistory.canUndo(DefaultOperationHistory.java:268) org.eclipse.ui.operations.UndoActionHandler.shouldBeEnabled(UndoActionHandler.java:82) org.eclipse.ui.operations.OperationHistoryActionHandler.update(OperationHistoryActionHandler.java:438) org.eclipse.ui.operations.OperationHistoryActionHandler$1.run(OperationHistoryActionHandler.java:144) org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) - locked org.eclipse.swt.widgets.RunnableLock@ea4462 org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) org.eclipse.equinox.launcher.Main.run(Main.java:1311) org.eclipse.equinox.launcher.Main.main(Main.java:1287) ============================================================== Name: Worker-0 State: TIMED_WAITING on org.eclipse.ui.internal.Semaphore@1515121 Total blocked: 1,802 Total waited: 4,736 Stack trace: java.lang.Object.wait(Native Method) org.eclipse.ui.internal.Semaphore.acquire(Semaphore.java:43) org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:168) org.eclipse.swt.widgets.Display.syncExec(Display.java:4312) org.eclipse.gmf.runtime.common.ui.action.AbstractContributionItem.historyNotification(AbstractContributionItem.java:658) org.eclipse.core.commands.operations.DefaultOperationHistory$2.run(DefaultOperationHistory.java:939) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.commands.operations.DefaultOperationHistory.notifyListeners(DefaultOperationHistory.java:928) org.eclipse.core.commands.operations.DefaultOperationHistory.notifyRemoved(DefaultOperationHistory.java:1052) org.eclipse.core.commands.operations.DefaultOperationHistory.internalRemove(DefaultOperationHistory.java:900) org.eclipse.core.commands.operations.DefaultOperationHistory.flushUndo(DefaultOperationHistory.java:629) - locked java.lang.Object@a70183 org.eclipse.core.commands.operations.DefaultOperationHistory.dispose(DefaultOperationHistory.java:334) org.eclipse.ui.operations.UndoActionHandler.flush(UndoActionHandler.java:53) org.eclipse.ui.operations.OperationHistoryActionHandler.update(OperationHistoryActionHandler.java:455) org.eclipse.gmf.runtime.common.ui.action.actions.global.GlobalUndoAction.refresh(GlobalUndoAction.java:258) org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandler.historyNotification(AbstractActionHandler.java:602) org.eclipse.core.commands.operations.DefaultOperationHistory$2.run(DefaultOperationHistory.java:939) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.core.commands.operations.DefaultOperationHistory.notifyListeners(DefaultOperationHistory.java:928) org.eclipse.core.commands.operations.DefaultOperationHistory.notifyAdd(DefaultOperationHistory.java:990) org.eclipse.core.commands.operations.DefaultOperationHistory.add(DefaultOperationHistory.java:190) org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:528) org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208) org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165) org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219) org.eclipse.tigerstripe.workbench.ui.visualeditor.adaptation.clazz.sync.ClassDiagramSynchronizerUtils.updateEArtifact(ClassDiagramSynchronizerUtils.java:125) org.eclipse.tigerstripe.workbench.ui.visualeditor.adaptation.clazz.sync.ClassDiagramSynchronizerUtils.handleQualifiedNamedElementChanged(ClassDiagramSynchronizerUtils.java:74) org.eclipse.tigerstripe.workbench.ui.visualeditor.adaptation.clazz.sync.ClassDiagramSynchronizer.artifactChanged(ClassDiagramSynchronizer.java:298) org.eclipse.tigerstripe.workbench.internal.core.model.ArtifactManager.notifyArtifactChanged(ArtifactManager.java:1404) org.eclipse.tigerstripe.workbench.internal.core.model.ArtifactManager.addArtifact(ArtifactManager.java:1646) org.eclipse.tigerstripe.workbench.internal.core.model.ArtifactManager.artifactResourceAdded(ArtifactManager.java:2454) org.eclipse.tigerstripe.workbench.internal.core.TigerstripeWorkspaceNotifier$5.run(TigerstripeWorkspaceNotifier.java:186) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) org.eclipse.tigerstripe.workbench.internal.core.TigerstripeWorkspaceNotifier.broadcastArtifactResourceAdded(TigerstripeWorkspaceNotifier.java:179) org.eclipse.tigerstripe.workbench.internal.core.TigerstripeWorkspaceNotifier.access$1(TigerstripeWorkspaceNotifier.java:172) org.eclipse.tigerstripe.workbench.internal.core.TigerstripeWorkspaceNotifier$2.run(TigerstripeWorkspaceNotifier.java:129) org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Created attachment 172383 [details]
jstack dump
I just have an hourglass still. At the bottom it says "Handle Artifact Resource Add" Yuri? Could you have a look here. Richard would be able to answer your questions on the context as needed i'm sure. Thanks, Eric Hi Eric, Sure, I'll look. There is GMF issue: bug 300451. It's already fixed in the 2.3.0 version which is available as M7. I can check tigerstripe compatibility with the latest GMF if you are ready to migrate to new GMF before release. (In reply to comment #6) > There is GMF issue: bug 300451. > It's already fixed in the 2.3.0 version which is available as M7. I can check > tigerstripe compatibility with the latest GMF if you are ready to migrate to > new GMF before release. Hi Yuri, yes. please have a look at the compatibility of Tigerstripe with this version of GMF. We are unlikely to move to Helios before at least another month at best, so we may want to migrate to this version of GMF within Ganymede in the meantime. Eric Looking at https://bugs.eclipse.org/bugs/show_bug.cgi?id=300451 It contains a patch - can't we patch our version ? Okay, I found that the latest GMF requires the latest EMF which is incompatible with eclipse 3.5 (some internal error while loading). So we can't just use the latest GMF. I think Chris suggestion makes sense if you can provide patched GMF version for your users. Also I've briefly check Tigerstripe on the Helios. There are two types of compile errors: 1. Some internal JDT messages was removed (need to move these messages to Tigerstripe). 2. OCL API was refactored so visual editor diagram should be regenerated. So I think there are not a lot of work to migrate to 3.6. (In reply to comment #9) > Okay, I found that the latest GMF requires the latest EMF which is incompatible > with eclipse 3.5 (some internal error while loading). So we can't just use the > latest GMF. > > I think Chris suggestion makes sense if you can provide patched GMF version for > your users. > > Also I've briefly check Tigerstripe on the Helios. There are two types of > compile errors: > 1. Some internal JDT messages was removed (need to move these messages to > Tigerstripe). > 2. OCL API was refactored so visual editor diagram should be regenerated. > > So I think there are not a lot of work to migrate to 3.6. Thanks for the analysis. The migration to 3.6 was on the to-do list, so maybe we should bite the bullet sooner than later. The re-generation of the visual editor diagram scares me a bit because we have A LOT OF custom code there. This will require quite a bit of testing. Probably worth branching making the changes in a branch until we're satisfied with the result? Thanks, ERic Hi Eric, I think it makes sense. And I can start with careful migration to 3.6 in a branch tomorrow if there are no other critical issues. So when I'll finish you can test all these stuff from your side before we'll move this version to HEAD. Is it work for you? (In reply to comment #11) > Hi Eric, > > I think it makes sense. And I can start with careful migration to 3.6 in a > branch tomorrow if there are no other critical issues. So when I'll finish you > can test all these stuff from your side before we'll move this version to HEAD. > Is it work for you? Perfect! Could we please have the patch as a higher priority than branching and working on a new version of Tigerstripe. I'd like to have TS patched by the end of this week in Surf/Pulse please ! (In reply to comment #13) > Could we please have the patch as a higher priority than branching and working > on a new version of Tigerstripe. > > I'd like to have TS patched by the end of this week in Surf/Pulse please ! Hi Chris, the patch is on the source for GMF. Delivering it thru Pulse will require: - time to set up an update site with this specific patch-ed GMF code - changing the pulse blueprints to point at that - working with the Pulse team to make this happen. There is at least 2-3 days to coordinate all this. Maybe Yuri can try and re-building GMF with this patch and provide this as a zip file for you to use and validate first? It seems nearly impossible to have that all integrated in Pulse by the end of the week unless we drop everything else. Eric Next week is OK with me, but I don't want to have to wait for an upgrade to a new version of eclipse. If the patched JAR has a later date can we just put it in our dropins directory to replace the buggy JAR ? (will OSGI pick it up in preference ?) The fix is in one class file only so will we need only need one JAR ? or do we need a complete update of GMF ? In summary, we need a fix for this quickly. I am open to consider any reasonable way of fixing this ! (In reply to comment #15) > Next week is OK with me, but I don't want to have to wait for an upgrade to a > new version of eclipse. > > If the patched JAR has a later date can we just put it in our dropins directory > to replace the buggy JAR ? (will OSGI pick it up in preference ?) > > The fix is in one class file only so will we need only need one JAR ? or do we > need a complete update of GMF ? > > In summary, we need a fix for this quickly. > I am open to consider any reasonable way of fixing this ! Ok. Let's see if we can provide a .zip file to unzip in your install in the dropins dir by the end of the week. Yuri to comment. Repoened until patch fix available Created attachment 173066 [details] patched GMF plugin where resolved bug 300451 Theoretically it would be enough to put this jar to plugins dir or create dropins for that and eclipse automatically choose the latest version. But in practice sometimes it's hard to update eclipse configuration with some new plugins because of P2 issues. The simpliest way is "eclipse -clean" after installation of the new plugins but it doesn't work sometimes... Thanks Yuri, I'll try it and see if it fixes the problem. I think this issue can be closed. |