Community
Participate
Working Groups
This one is weird. I installed Mylyn 2.0 RC4 into Eclipse 3.3 RC4 on OSX. I had been using the workspace for a while, but it had never had Mylar or Mylyn installed. I added a couple of CollabNet Issue Tracker repositories and queries and all was working well. I even closed and reopened Eclipse a couple times. I then tried to Activate a Task. The preferences dialog popped up but before I could click it, Eclipse just crashed, no stack trace, nothing. Like the error was at the OSX level. I repeated this several more times. Sometimes Eclipse would crash before the dialog, sometimes after. To rule out the CollabNet plug-ins I decided to create a Local Task. That also crashed Eclipse immediately. Finally, after restarting Eclipse I went to preferences and just opened the Mylyn preferences and clicked through them. Did not really change anything. Once I did that, the problem just went away. I could add Local Tasks and activate/de-activate any task. I do not really know if it was related to visiting the preferences or not. Sorry I do not have better info. I am going to try to test on Windows and see what that does.
If Eclipse crashes with no warning the cause is usually a VM and/or OS bug. At or around the time of this a lot of plug-in activation could be happening. Are you able to reproduce this in a runtime workspace where you could set a breakpoint to figure out who/what we should blame and try to fix or work around?
I'll give some of that a try. I could not recreate it on Windows. I agree with your analysis, I figured it might be some kind of SWT-level problem since usually only native code would cause a crash like this. The weird part is that I have been using this workspace for a couple weeks without problems, and it was only when taking these Mylyn actions that the problem occurs.
Created attachment 72546 [details] Crash details OK, I ran this in debug (no breakpoints set yet). It crashed when trying to add a new Local Task. I have attached the crash report that OSX wanted to send to Apple. Given this crash point can you give me some ideas on where to set a break point?
I see nothing familiar in that stack. Here is what would be good to try: * Get the latest nightly build of Eclipse 3.3 * Set a breakpoint in TasksUiPlugin.getTaskListManager().activateTask(..); Note that many listeners get called, and some of them could be causing other activations. But you should at least be able to dump some output before and after the listener notification.
I was able to set a breakpoint in NewTaskAction.run(). Of course now it does not crash. Remove the breakpoint and it crashes again. Sorry I could not be more help. I might be able to get back to this later in the week. Hopefully it is going to be specific to my system.
Thanks Mark. The breakpoint behavior you are witnessing could indicate that this is some weird VM condition with class loading or activation. The best way now to figure out what triggers it is probably a thread dump, some pointers are on the 3rd bullet of the following: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Debugging
Lowering priority until we have additional input.
We are able to reproduce this on a Mac. Investigating...
I'm posting 2 thread dumps from the OSX log. The first occurred after attempting to create a new query, the second after trying to activate a task. At first I was able to reproduce these crashes, but now I'm having difficulty trying to reproduce. I don't know what's the cause of such erratic behaviour. --------------- T H R E A D --------------- Current thread (0x02802000): JavaThread "main" [_thread_in_native, id=-1610559488] Stack: [0xbf800000,0xc0000000) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.carbon.OS.ShowWindow(I)V+0 j org.eclipse.swt.widgets.Shell.setWindowVisible(Z)V+163 j org.eclipse.swt.widgets.Shell.setVisible(Z)V+57 j org.eclipse.swt.widgets.Shell.open()V+11 j org.eclipse.jface.window.Window.open()I+34 j org.eclipse.mylyn.internal.tasks.ui.actions.NewQueryAction.run(Lorg/eclipse/jface/action/IAction;)V+195 j org.eclipse.ui.internal.PluginAction.runWithEvent(Lorg/eclipse/swt/widgets/Event;)V+110 j org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(Lorg/eclipse/swt/widgets/Event;Z)V+278 j org.eclipse.jface.action.ActionContributionItem.access$2(Lorg/eclipse/jface/action/ActionContributionItem;Lorg/eclipse/swt/widgets/Event;Z)V+3 j org.eclipse.jface.action.ActionContributionItem$5.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+60 J org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V J org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;Z)V j org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;)V+4 j org.eclipse.swt.widgets.Widget.notifyListeners(ILorg/eclipse/swt/widgets/Event;)V+19 j org.eclipse.swt.widgets.Display.runDeferredEvents()Z+88 j org.eclipse.swt.widgets.Display.readAndDispatch()Z+98 j org.eclipse.ui.internal.Workbench.runEventLoop(Lorg/eclipse/jface/window/Window$IExceptionHandler;Lorg/eclipse/swt/widgets/Display;)V+9 j org.eclipse.ui.internal.Workbench.runUI()I+336 j org.eclipse.ui.internal.Workbench.access$4(Lorg/eclipse/ui/internal/Workbench;)I+1 j org.eclipse.ui.internal.Workbench$4.run()V+23 j org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12 j org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+18 j org.eclipse.ui.PlatformUI.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+2 j org.eclipse.ui.internal.ide.application.IDEApplication.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+81 j org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/Object;)Ljava/lang/Object;+100 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ljava/lang/Object;)Ljava/lang/Object;+103 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/lang/Object;)Ljava/lang/Object;+29 j org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/Object;)Ljava/lang/Object;+149 j org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/String;Ljava/lang/Runnable;)Ljava/lang/Object;+183 v ~StubRoutines::call_stub j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+208 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+114 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 j org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10 v ~StubRoutines::call_stub --------------- T H R E A D --------------- Current thread (0x02801800): JavaThread "main" [_thread_in_native, id=-1610559488] Stack: [0xbf800000,0xc0000000) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.carbon.OS.ShowWindow(I)V+0 j org.eclipse.swt.widgets.Shell.setWindowVisible(Z)V+163 j org.eclipse.swt.widgets.Shell.setVisible(Z)V+57 j org.eclipse.swt.widgets.Shell.open()V+11 j org.eclipse.jface.window.Window.open()I+34 j org.eclipse.ui.internal.progress.BlockedJobsDialog$1.runInUIThread(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+24 j org.eclipse.ui.progress.UIJob$1.run()V+51 j org.eclipse.swt.widgets.RunnableLock.run()V+11 j org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Z)Z+29 j org.eclipse.swt.widgets.Display.runAsyncMessages(Z)Z+5 j org.eclipse.swt.widgets.Display.readAndDispatch()Z+111 j org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.runEventLoop()V+39 j org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor.isCanceled()Z+1 j org.eclipse.core.internal.jobs.ThreadJob.isCanceled(Lorg/eclipse/core/runtime/IProgressMonitor;)Z+1 j org.eclipse.core.internal.jobs.ThreadJob.joinRun(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/internal/jobs/ThreadJob;+84 J org.eclipse.core.internal.jobs.ImplicitJobs.begin(Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;Z)V J org.eclipse.core.internal.resources.WorkManager.checkIn(Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V J org.eclipse.core.internal.resources.Workspace.prepareOperation(Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V j org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;ILorg/eclipse/core/runtime/IProgressMonitor;)V+39 j org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/IProgressMonitor;)V+8 j org.eclipse.mylyn.internal.java.ui.LandmarkMarkerManager.landmarkAdded(Lorg/eclipse/mylyn/context/core/IInteractionElement;)V+105 j org.eclipse.mylyn.internal.java.ui.LandmarkMarkerManager.modelUpdated()V+78 j org.eclipse.mylyn.internal.java.ui.LandmarkMarkerManager.contextActivated(Lorg/eclipse/mylyn/context/core/IInteractionContext;)V+1 j org.eclipse.mylyn.internal.context.core.InteractionContextManager.activateContext(Ljava/lang/String;)V+68 j org.eclipse.mylyn.tasks.ui.TasksUiPlugin$1.taskActivated(Lorg/eclipse/mylyn/tasks/core/AbstractTask;)V+7 j org.eclipse.mylyn.tasks.ui.TaskListManager.activateTask(Lorg/eclipse/mylyn/tasks/core/AbstractTask;)V+43 j org.eclipse.mylyn.internal.tasks.ui.actions.TaskActivateAction.run(Lorg/eclipse/mylyn/tasks/core/AbstractTask;)V+15 j org.eclipse.mylyn.internal.tasks.ui.views.TaskListCellModifier.toggleTaskActivation(Lorg/eclipse/mylyn/tasks/core/AbstractTaskContainer;)V+57 j org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$8.mouseDown(Lorg/eclipse/swt/events/MouseEvent;)V+80 j org.eclipse.swt.widgets.TypedListener.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+742 J org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V J org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;Z)V j org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;)V+4 j org.eclipse.swt.widgets.Widget.notifyListeners(ILorg/eclipse/swt/widgets/Event;)V+19 j org.eclipse.swt.widgets.Display.runDeferredEvents()Z+88 j org.eclipse.swt.widgets.Control.sendTrackEvents()V+6 j org.eclipse.swt.widgets.Control.kEventControlTrack(III)I+53 J org.eclipse.swt.widgets.Widget.controlProc(III)I J org.eclipse.swt.widgets.Display.controlProc(III)I v ~StubRoutines::call_stub J org.eclipse.swt.internal.carbon.OS.CallNextEventHandler(II)I j org.eclipse.swt.widgets.Tree.kEventMouseDown(III)I+29 j org.eclipse.swt.widgets.Widget.mouseProc(III)I+68 j org.eclipse.swt.widgets.Display.mouseProc(III)I+464 v ~StubRoutines::call_stub j org.eclipse.swt.internal.carbon.OS.SendEventToEventTarget(II)I+0 j org.eclipse.swt.widgets.Display.readAndDispatch()Z+52 j org.eclipse.ui.internal.Workbench.runEventLoop(Lorg/eclipse/jface/window/Window$IExceptionHandler;Lorg/eclipse/swt/widgets/Display;)V+9 j org.eclipse.ui.internal.Workbench.runUI()I+336 j org.eclipse.ui.internal.Workbench.access$4(Lorg/eclipse/ui/internal/Workbench;)I+1 j org.eclipse.ui.internal.Workbench$4.run()V+23 j org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12 j org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+18 j org.eclipse.ui.PlatformUI.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+2 j org.eclipse.ui.internal.ide.application.IDEApplication.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+81 j org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/Object;)Ljava/lang/Object;+100 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ljava/lang/Object;)Ljava/lang/Object;+103 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/lang/Object;)Ljava/lang/Object;+29 j org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/Object;)Ljava/lang/Object;+149 j org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/String;Ljava/lang/Runnable;)Ljava/lang/Object;+183 v ~StubRoutines::call_stub j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+208 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+114 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 j org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10 v ~StubRoutines::call_stub
Created attachment 72554 [details] Disabling task list tooltips on Mac Bug 125656 has some insight on what might be causing this problem.
Created attachment 72555 [details] mylyn/context/zip
Here is a short summary of the mammoth diagnosis and debugging session that Rob, Leo and I just had to get to the bottom of this. When a context menu is popped up on the Mac a tooltip could pop behind it, having both the tooltip and the context menu show. When SWT tried to open a new shell in this scenario (e.g. settings wizard with task activation, query wizard) a Mac JVM bug would be triggerred causing the crash. To work around it we have disabled tooltips on Mac. Eugene: We ran out of time to investigate, but since this was not happening with earlier builds there is a strong suspicion that this is from your patch on bug 166406. Please investigate and report back anything you can think of having caused this (and perhaps the pop-behind behavior on Linux and Mac) because otherwise we may get stuck with no tooltips on Mac if there isn't sufficient time to pull out the patch or determine the cause. Steffen: Did you just notice this today on Linux, as per bug 194510, or had you seen the behavior earlier? Mark: Later tonight or early morning tomorrow we'll have a 3.3 build with a fix for this so please verify. Note that this has delayed the 3.2 build, but it wille be out along with the updated 3.3 one.
(In reply to comment #12) > Eugene: We ran out of time to investigate, but since this was not happening with > earlier builds there is a strong suspicion that this is from your patch on bug > 166406. Please investigate and report back anything you can think of having > caused this (and perhaps the pop-behind behavior on Linux and Mac) because > otherwise we may get stuck with no tooltips on Mac if there isn't sufficient > time to pull out the patch or determine the cause. Hmm. I don't think I changed anything about positioning or tooltip activation (there is separate bug 189313 about positioning). Changes were about inner layout and added some additional text. Because of the latter tooltip grown in size, could potentially increased chances for described overlap or some other corner cases (i.e. tooltip don't fit into the screen and gets shifted). Unfortunately I don't have Mac to test this issue.
I think I just realized which change triggered this bug: In TaskListToolTipHandler rev 1.40 the tooltip was hidden when a mouseDown() event occurred but tipWidget was not set to null. That means when a mouseHover() event occurred this statement: if (widget == tipWidget) return; would be true and the method would exit without showing the tooltip.
Mik, removing tipWidget = null; from mouseExit() should restore the old behavior.
By the way, we may want to use JFace tooltip support instead of this custom stuff, though it is probably not going to work on 3.2...
But it does not fix the problem... I'll investigate further.
Created attachment 72617 [details] revert from disposing tooltip widget to setting is invisible This patch reverts some of the changes made in a recent refactoring of the tooltip handler. As Leo pointed out in comment 10 the crash is caused by disposing the tooltip. Mik, I can't test this on Mac and it might be safest to rollback to the original tooltip implementation (rev. 1.40) or to leave tooltips disabled.
I've tested your patch Steffen. I open a context menu, wait for the tooltip to show up behind it, then call new query from the menu. When the dialog shows up, tooltip disappears and we get no crash. Looks like this is the fix.
Good to hear. We need to document this in the class to avoid reintroducing this.
Patch applied and merged back to 3.2. Shawn, Leo, and I all reviewed it. Thanks for identifying and fixing the problem Steffen, it would have been a shame to go out on Mac with no tooltips. Steffen: The only change in question was the lack of "tipShell = null;" but that looks fine, was it related to the regression? All: please bootstrap on this since we will be doing a final 3.3 build in approximately 2 hours.
It seems to be fixed for me.
(In reply to comment #21) > Steffen: The only change in question was the lack of "tipShell = null;" but that > looks fine, was it related to the regression? Are you referring to tipWidget = null in mouseDown()? It should not make a difference but I took it out because the old implementation did not have it.
Thanks for looking into that Steffen, and thanks for verifying Mark. This one is definitely going to make the Mylyn 2.0 war stories!
Changing OS from Mac OS to Mac OS X as per bug 185991
