Community
Participate
Working Groups
Build Identifier: M20100909-0800 After playing around with reordering items in Outline view Eclipse crashed. Reproduced a few times. Eclipse version 3.6.1 with SWT Carbon. Attaching the crash report. Reproducible: Always
Created attachment 185389 [details] Crash file
Created attachment 185390 [details] Crash file Another crash file with slightly different stacktrace.
Sometimes I also get the following NullPointerException. I think this happens after I try to drop an item over itself. I get a "drop denied" cursor but looks like the drop has a side effect. The stacktrace: java.lang.NullPointerException at org.eclipse.gef.ui.parts.TreeViewer$1.widgetSelected(TreeViewer.java:193) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1669) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1693) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1678) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1421) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3653) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3236) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) 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:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Peter, I cannot reproduce this with Eclipse 32-bit Carbon on Mac OS X Tiger (10.4.11, Java 5) with the logic example. I can also not reproduce it using Eclipse 64-bit Cocoa on Mac OS X Snow Leopard (10.6.5, Java 6) with the logic example. From the attached crash files I infer that you are actually using Eclipse 32-bit Carbon on a Mac OS X Snow Leopard (10.6.4). Is this correct?
The NPE however is reproducable on Mac Carbon, but I think this is a different issue.
Alexander, yes my version is 10.6.4. I see that there is version 10.6.6 available in updates. Would you like me to update and test with that?
Yes, you may, but my point was more concerned about your motivation of using the Carbon port on a Mac with Snow Leopard. As I stated, I cannot reproduce this problem on a Mac, where Carbon is the only choice (i.e. OS 10.4.11), and I can also not reproduce it one with Snow Leopard (10.6.5) using the Cocoa port. Nevertheless, from the attached crash files and the fact that I could not reproduce the issue with GEF on both ports, I infer there has to be some SWT problem underlying this, which seems to only occur using the Carbon port on Snow Leopard. It would thus be more interesting if we could identify an existing or create an SWT snippet, e.g. like the one I have attached to bug #333375, to reproduce the underlying issue with SWT means alone, so we could open an issue against SWT and provide detailed means on how to reproduce it for the SWT team. Could you support that?
Created bug #335515 to keep track of the NPE that occurs during reordering.
(In reply to comment #7) > Yes, you may, but my point was more concerned about your motivation of using > the Carbon port on a Mac with Snow Leopard. As I stated, I cannot reproduce > this problem on a Mac, where Carbon is the only choice (i.e. OS 10.4.11), and I > can also not reproduce it one with Snow Leopard (10.6.5) using the Cocoa port. > > Nevertheless, from the attached crash files and the fact that I could not > reproduce the issue with GEF on both ports, I infer there has to be some SWT > problem underlying this, which seems to only occur using the Carbon port on > Snow Leopard. It would thus be more interesting if we could identify an > existing or create an SWT snippet, e.g. like the one I have attached to bug > #333375, to reproduce the underlying issue with SWT means alone, so we could > open an issue against SWT and provide detailed means on how to reproduce it for > the SWT team. Could you support that? I can also not reproduce this using GEF (3.7M4) logic example with eclipse 3.7M4 x86 carbon on Mac OS X Snow Leopard (10.6.6), using vm 1.6.0_22 in 32-bit mode (-d32). Peter, can you please try to reproduce it with 3.7M4 on your machine?
Alexander, I don't have my Mac machine with me right now. The earliest I can give it a test will be in 3 weeks. Hope it won't be too late.
Hi Peter. Were you able to reproduce the bug? I was unable to reproduce it in Windows build M20110909-1335 Thanks
Arieh, this is a Mac problem and not Windows.
As this is not reproducible and as Mac Carbon is no longer supported, resolving it as WONTFIX.
