Comment 1 Bryan Hunt 2008-11-01 12:34:52 EDT

It seems this problem is not 100% reproducible.  I don't have an exact set of steps right now.

Comment 2 Carolyn MacLeod 2008-11-03 13:03:00 EST

Not sure if it is related, but I have a similar problem - Window->Show View-> Other... and then I type "Error" in the filter to get the Error Log, and double click that - nothing happens. The stack trace in my .log file is:

!ENTRY org.eclipse.ui 4 0 2008-11-03 12:59:49.886
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.ClassCastException: org.eclipse.ui.internal.registry.ViewDescriptor
	at org.eclipse.ui.internal.dialogs.ShowViewDialog.saveWidgetValues(ShowViewDialog.java:368)
	at org.eclipse.ui.internal.dialogs.ShowViewDialog.buttonPressed(ShowViewDialog.java:107)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:625)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1097)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1121)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1106)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:933)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2923)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2656)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
	at org.eclipse.jface.window.Window.open(Window.java:801)
	at org.eclipse.ui.handlers.ShowViewHandler.openOther(ShowViewHandler.java:100)
	at org.eclipse.ui.handlers.ShowViewHandler.execute(ShowViewHandler.java:77)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:281)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
	at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
	at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:247)
	at org.eclipse.ui.internal.ShowViewMenu$3.run(ShowViewMenu.java:134)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:412)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1097)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1121)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1106)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:933)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2923)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2656)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:333)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
	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:370)
	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:585)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1236)

Comment 3 Ryan Wilhm 2008-11-05 05:46:49 EST

I have been able to reproduce the problem Carolyn describes. The stack traces look to point to different problems... The original defect looks like it can't create the dialog itself, whereas the second stack trace successfully creates the dialog, but the filtered tree is updated improperly when the user types a string. 

I've been debugging the latter problem, and found that when the filtered tree is updated, it includes the raw view descriptors in the expanded elements list. When saving the expanded categories in the view dialog before opening the view, it tries to cast those raw view descriptors to iviewcategory (hence the CCE). It works fine if the user doesn't enter a filter string. In that case, only the expanded categories are returned as expanded elements.

Comment 4 Ryan Wilhm 2008-11-05 08:21:49 EST

Created attachment 117065 [details]
Patch to fix ClassCastException on filtered view dialog

I think I'd found the problem that Carolyn reported (CCE on using the text filter to narrow the tree of views in the Show View dialog). The algorithm in the view dialog that auto-expands/collapses the tree when updated by the filter text actually goes ahead and tries to "expand" a TreeItem even if it's a leaf. Other platforms seem to preempt this, or pass the call through to the native layer (which does the sanity checking for us).

In the current Cocoa class, the "expanded" state is stored regardless of whether it reflects reality on the native side.

This one-liner patch preempts setting the "expanded" state in TreeItem if there are no children contained within the node.

Tested a bit this morning, and seems to work fine in my environment.

Comment 5 Ryan Wilhm 2008-11-05 08:21:55 EST

Created attachment 117066 [details]
mylyn/context/zip

Comment 6 Steve Northover 2008-11-05 09:54:40 EST

Kevin or Grant, just fix this please.

Comment 7 Grant Gayed 2008-11-05 15:20:41 EST

Comment on attachment 117065 [details]
Patch to fix ClassCastException on filtered view dialog

Thanks for investigating this!  I've released a fix based on the patch > 1105 and will add you to the contributors list.

Keeping report open because I don't think this addresses the original problem.

Comment 8 Grant Gayed 2008-11-05 16:08:19 EST

*** Bug 253069 has been marked as a duplicate of this bug. ***

Comment 9 Grant Gayed 2008-11-05 16:09:13 EST

Bug 253069 says the original problem happens in the area of bread crumb menus as well.

Comment 10 Ryan Wilhm 2008-11-12 13:16:56 EST

I have been unable to reproduce the original problem in this defect on two separate systems for the past few days when I have spare cycles, including one in dual-head configuration.

I've been looking more critically at the stack traces attached. Both the ?Window->Show View->Other...? and the bread crumb defect encounter NPEs in a line where we know the ?window? variable is the NPE cause. (Line 491 of Display.java also references ?cascade?, which would just be passed as null since its used as a parameter (and is explicitly initialized in the code anyway if null), and ?screenCascade?, which was referenced with an index earlier in the method and would have caused problems there if it had not already been initialized. The ?window? instance is passed in, and not called until the line of the NPE where the ?cascadeTopLeftFromPoint? method is invoked.)

Walking back one step in the stack trace, the snippet where ?window? is assigned and subsequently passed into ?Display.cascadeWindow(NSWindow, NSScreen)? is the following from ?Shell.createHandle()?:

--
window = window.initWithContentRect(new NSRect(), styleMask, OS.NSBackingStoreBuffered, false, screen);
if ((style & (SWT.NO_TRIM | SWT.BORDER | SWT.SHELL_TRIM)) == 0) {
		window.setHasShadow (true);
}
display.cascadeWindow(window, screen);
--

So, we know that ?window? is not null for the initWithContentRect call, but possibly is immediately after since it's reassigned to whatever the return value is. The call to ?window? within the if statement is only made if the ?style? value doesn't match the mask. We can assume that it does, since this would have generated an NPE within the if statement.

We can assert that the null condition is created by the call to ?NSWindow.initWithContentRect(..)? under the condition where ?style? matches the (SWT.NO_TRIM | SWT.BORDER | SWT.SHELL_TRIM) mask.

Looking at ?NSWindow.initWithContentRect(..)? to see what conditions would possibly result in returning a null value:

?
int /*long*/ result = OS.objc_msgSend(this.id, OS.sel_initWithContentRect_styleMask_backing_defer_screen_, contentRect, aStyle, bufferingType, flag, screen != null ? screen.id : 0);
	return result == this.id ? this : (result != 0 ? new NSWindow(result) : null);
?

This is the likely culprit, as it returns null if the native call fails and returns NSWindow identifier 0. The native call to the NSWindow passed in is to NSWindow.initWithContentRect(..). Looking at it's parameters:

?contentRect? is simply a newly constructed NSRect. ?aStyle? is set before the call. ?bufferingType? is OS.NSBackingStoreBuffered. ?screen? is determined from the ?Shell.createHandle()? call.

Looking at the Cocoa API, ?screen? can be nil, so this would only be culprit if the instance passed had an invalid ?screen.id? value. (Referring to a native NSScreen that doesn't exist as an instance.) This seems unlikely though, because before this call is made, the ?createHandle()? method goes through some work to sanity-check the value that ultimately gets passed in, defaulting to the main screen if it can't find the screen for the ?parent? (or if its screen is null for some reason.) Ultimately, this ?screen? instance would only be bogus if the ?NSScreen.screens().objectAtIndex(0)? call returns a bogus instance reference (non-nil and non-existent), or if the same were true about the screen instance set in the ?parent?.

Another possibility is if the same thing happened to the passed in ?window? instance. (i.e., the instance exists on the Java side, but has been disposed or invalidated on the native side so that ?window.id? no longer points to an existing instance. (Perhaps if the initial call to new SWTWindow.alloc() fails?)

To me, it seems like those two would be the main candidates for this failure. If the problem still actually exists, its intermittent. The only thing that I can see to really do at this point is put some logging in place to capture state (if there's anything in place to check whether the NSObject.id values on the Java side can sanity check whether they point to a real instance on the native side before actually attempting the dynamic dispatch call...)

Comment 11 Kevin Barnes 2009-03-17 10:53:13 EDT

fixed