Community
Participate
Working Groups
I'm not sure where the root cause of this exception is, so I'm opening this against Plaform for starters. While debugging Eclipse, I routinely hit exceptions like the following: !ENTRY org.eclipse.ui.workbench 4 2 2006-04-19 12:12:44.505 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". !STACK 0 org.eclipse.core.runtime.AssertionFailedException: null argument: at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:84) at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:71) at org.eclipse.core.expressions.EvaluationContext.getVariable(EvaluationContext.java:130) at org.eclipse.ui.internal.expressions.WorkbenchWindowExpression.evaluate(WorkbenchWindowExpression.java:80) at org.eclipse.ui.internal.expressions.LegacyViewerContributionExpression.evaluate(LegacyViewerContributionExpression.java:111) at org.eclipse.ui.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:55) at org.eclipse.ui.internal.expressions.AndExpression.evaluate(AndExpression.java:46) at org.eclipse.ui.internal.services.EvaluationResultCache.evaluate(EvaluationResultCache.java:74) at org.eclipse.ui.internal.services.ExpressionAuthority.evaluate(ExpressionAuthority.java:159) at org.eclipse.ui.internal.handlers.HandlerAuthority.sourceChanged(HandlerAuthority.java:394) at org.eclipse.ui.internal.services.ExpressionAuthority.sourceChanged(ExpressionAuthority.java:279) at org.eclipse.ui.AbstractSourceProvider.fireSourceChanged(AbstractSourceProvider.java:79) at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider.selectionChanged(CurrentSelectionSourceProvider.java:115) at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider.swapListeners(CurrentSelectionSourceProvider.java:137) at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider.access$0(CurrentSelectionSourceProvider.java:131) at org.eclipse.ui.internal.services.CurrentSelectionSourceProvider$1.windowDeactivated(CurrentSelectionSourceProvider.java:62) at org.eclipse.ui.internal.Workbench$9.run(Workbench.java:625) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.Workbench.fireWindowDeactivated(Workbench.java:623) at org.eclipse.ui.internal.WorkbenchWindow$7.shellDeactivated(WorkbenchWindow.java:2698) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:168) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:925) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:949) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:930) at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1588) at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:1714) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3244) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1539) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:1634) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4023) at org.eclipse.swt.internal.win32.OS.BringWindowToTop(Native Method) at org.eclipse.swt.widgets.Decorations.bringToTop(Decorations.java:183) at org.eclipse.swt.widgets.Shell.open(Shell.java:997) at org.eclipse.jface.window.Window.open(Window.java:792) at org.eclipse.jface.dialogs.MessageDialog.openError(MessageDialog.java:322) at org.eclipse.jface.util.SafeRunnable.handleException(SafeRunnable.java:60) at org.eclipse.core.runtime.SafeRunner.handleException(SafeRunner.java:68) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:39) at org.eclipse.ui.internal.Workbench.fireWindowDeactivated(Workbench.java:623) at org.eclipse.ui.internal.WorkbenchWindow$7.shellDeactivated(WorkbenchWindow.java:2698) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:168) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:925) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:949) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:930) at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1588) at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:1714) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3244) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1539) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:1634) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4023) at org.eclipse.swt.internal.win32.OS.BringWindowToTop(Native Method) at org.eclipse.swt.widgets.Decorations.bringToTop(Decorations.java:183) at org.eclipse.swt.widgets.Shell.open(Shell.java:997) at org.eclipse.jface.window.Window.open(Window.java:792) at org.eclipse.jface.dialogs.MessageDialog.openError(MessageDialog.java:322) at org.eclipse.jface.util.SafeRunnable.handleException(SafeRunnable.java:60) at org.eclipse.core.runtime.SafeRunner.handleException(SafeRunner.java:68) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:39) at org.eclipse.ui.internal.Workbench.fireWindowDeactivated(Workbench.java:623) at org.eclipse.ui.internal.WorkbenchWindow$7.shellDeactivated(WorkbenchWindow.java:2698) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:168) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:925) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:949) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:930) at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1588) at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:1714) Once hit, these can spawn infinate looping where a SafeRunner generates an exception, tries to open a dialog, fails, tries to generate an exception, fails, tries to open a dialog, etc .... These errors bring the entire workbench down. I'm running on an IBM JRE 5.0 and though that it might have been related to J9 hotswapping. Part of the reason I thought it might have been a hotswapping concern is due to a NullPointerException on the following lines in ActionContributionItem.update(String): 771: if (("gtk".equals(SWT.getPlatform())) && (callback instanceof BindingManagerCallback) //$NON-NLS-1$ 772: && (commandId != null)) { 773: final IBindingManagerCallback bindingManagerCallback = (IBindingManagerCallback) callback; 774: final IKeyLookup lookup = KeyLookupFactory.getDefault(); With a little investigating, I found that the only way this NPE could have been generated was for "gtk" to be null. I have seen similar behavior in other places where static constants are seemingly null. Sometimes this is after a hotswap, but I see it now even outside of J9. These particular lines cause the problem of crashing the workbench around 80% of the time. The crash almost always occurs when clicking back onto the Development Eclipse instance from the debuging Eclipse instance. I will attach three separate logs that show these errors.
Created attachment 38947 [details] Crash
Created attachment 38948 [details] Crash
Created attachment 38950 [details] Crash
Sounds like a flaky VM build to me... can you try with another VM? I believe this NPE in the log is also impossible in a well-behaved VM: java.lang.NullPointerException at java.lang.String.startsWith(String.java:1009) at java.lang.String.startsWith(String.java:994) at org.eclipse.osgi.framework.internal.core.ServiceReferenceImpl.isAssignableTo(ServiceReferenceImpl.java:229) Can you confirm that these errors are happening in the debug instance of Eclipse and not your development instance?
The errors do occur in the development target, not the instance of Eclipse that I am primaryly developing in. Both Eclipse instances (target and development) are running a 5.0 JRE. I can switch to an IBM JRE 1.4.2 and watch for the problem to pop up again. I'm 75% sure though that I've seen the issue on the 1.4.2sr1 JVM as well though; so I'm not really convinced it's _only_ a JVM issue. I'm not familiar with the OSGI layers enough to credibly theorize here, but do they handle thier own class(re-)loading for bundle classloading?
OSGi has its own class loaders, but a ClassLoader subclass is just responsible for figuring out where to get the bytes of the class file from. They don't have the power to, for example, make constants null.
No news from Michael, closing for now.
After an upgrade of my JRE, I no longer saw these issues. I chaulked them up to a bug in the JRE hotswap routines. Closing as invalid is fine with me.
