Community
Participate
Working Groups
Happened in a recent 4.1 stream build. I had a bunch of incoming changes in the sync view (displayed as change sets), selected them all and picked "Update". While the tree in the sync view changed (the change sets disappeared incrementally), I tried to expand one of the items, hoping to see what the change set contained before it disappeared. The crash may have happened because the item to expand didn't exist anymore when the event was processed. I'm going to attach the thread dump. Here are the first few lines from it: Process: eclipse [218] Path: /Users/bokowski/Desktop/4.1M2a/Eclipse.app/Contents/MacOS/eclipse Identifier: org.eclipse.eclipse Version: 3.6 (3.6) Code Type: X86-64 (Native) Parent Process: launchd [70] Interval Since Last Report: 22944436 sec Crashes Since Last Report: 5 Per-App Interval Since Last Report: 2683260 sec Per-App Crashes Since Last Report: 1 Date/Time: 2010-09-27 10:40:39.631 -0400 OS Version: Mac OS X 10.5.8 (9L31a) Report Version: 6 Anonymous UUID: 16031B24-5279-4D25-9BB4-90858BD86F29 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000770000c577 Crashed Thread: 0 Application Specific Information: Java information: Exception type: Bus Error (0xa) at pc=7fff81d8ff78 Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode macosx-amd64) Current thread (112801000): JavaThread "main" [_thread_in_native, id=1885091584, stack(7fff5f400000,7fff5fc00000)] Stack: [7fff5f400000,7fff5fc00000] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.eclipse.swt.internal.cocoa.OS.object_getInstanceVariable(J[B[J)J J org.eclipse.swt.widgets.Display.getWidget(J)Lorg/eclipse/swt/widgets/Widget; j org.eclipse.swt.widgets.Tree.expandItem_expandChildren(JJJZ)V+6 j org.eclipse.swt.widgets.Display.windowProc(JJJJ)J+384 v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J j org.eclipse.swt.widgets.Widget.callSuper(JJJ)V+32 j org.eclipse.swt.widgets.Widget.mouseDownSuper(JJJ)V+5 j org.eclipse.swt.widgets.Tree.mouseDownSuper(JJJ)V+200 j org.eclipse.swt.widgets.Widget.mouseDown(JJJ)V+5 j org.eclipse.swt.widgets.Control.mouseDown(JJJ)V+42 j org.eclipse.swt.widgets.Tree.mouseDown(JJJ)V+192 J org.eclipse.swt.widgets.Display.windowProc(JJJ)J v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J j org.eclipse.swt.widgets.Widget.callSuper(JJJ)V+32 j org.eclipse.swt.widgets.Widget.windowSendEvent(JJJ)V+5 j org.eclipse.swt.widgets.Shell.windowSendEvent(JJJ)V+482 J org.eclipse.swt.widgets.Display.windowProc(JJJ)J v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J j org.eclipse.swt.widgets.Display.applicationSendEvent(JJJ)V+383 j org.eclipse.swt.widgets.Display.applicationProc(JJJ)J+67 v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJJ)J J org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run()V j org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12 j org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(Lorg/eclipse/e4/ui/model/application/MApplicationElement;Lorg/eclipse/e4/core/contexts/IEclipseContext;)Ljava/lang/Object;+19 j org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(Lorg/eclipse/e4/ui/model/application/MApplicationElement;)V+162 j org.eclipse.ui.internal.Workbench$3.run()V+124 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;+99 j org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/Object;)Ljava/lang/Object;+135 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;+137 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;+161 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+211 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+126 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 v ~StubRoutines::call_stub
Created attachment 179652 [details] thread dump
*** Bug 320403 has been marked as a duplicate of this bug. ***
I _think_ this just needs an isDisposed() check at the beginning of Tree#expandItem_expandChildren. It's hard to reproduce though.
I'm investigating this for RC2.
Created attachment 198397 [details] snippet to reproduce crash Expanding or Collapsing a tree node just when it is disposed causes the crash.
Created attachment 201650 [details] patch The patch checks if the item is disposed before calling display.getWidget(). Silenio, please review for 3.7.1.
Created attachment 201651 [details] patch-2
*** Bug 352857 has been marked as a duplicate of this bug. ***
Lakshmi, this patch does not apply properly using menu "Eclipse -> Team -> Apply Path". How did you generate it?
Created attachment 201655 [details] patch-2 Sorry! In the create patch wizard I had checked the 'export in git patch format' and created the previous patch. It has added some 'header' in the patch. Created a new patch without checking this option. This applies properly.
Created attachment 201661 [details] alternative patch The previous patch relies on the fact that NSOutlineView rowForItem: accepts invalid memory without causing a crash. It is probably doing just a lookup on hash table. This patch keeps the item id valid for the whole duration of the mouse down event. I am not sure which patch is better: - the first is relying on undocumented behaviour, but it might catch other cases where the item id gets disposed while still being used. - the second patch only catches the mouse down case and it only had minimal testing. Lakshmi, please could you test this patch? What do you think?
(In reply to comment #11) > Created attachment 201661 [details] > alternative patch > ... > Lakshmi, please could you test this patch? What do you think? Silenio, I think we could use this patch. All the crash reports for this bug show that the crash happened on mouse down, so it would fix these scenarios. Also, it is reliable compared to the other patch which uses the undocumented behavior of rowForItem: I have tested this patch with the snippets and it fixes the crashes, I'll test it further tomorrow.
Lakshmi, did you have a chance to test my patch? Should we release it to 3.7.1 and 3.8?
(In reply to comment #13) > Lakshmi, did you have a chance to test my patch? Should we release it to 3.7.1 > and 3.8? Hi Silenio, I have tested the patch already. I have been running my eclipse with this patch and it works well. I think we should fix this for 3.7.1.
Fixed in 3.8 and 3.7.1 branches. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6da7bd33cedeeac68f4b743d186c7b726a9e0f5b http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_7_maintenance&id=5de74e2a09f3a27a0803535c3b0d1d24c83f4135
We still have crashes in our application with swt 3.7.1 and swt 3.8m3 on Lion. It is however a lot less frequent... With Swt 3.7, the problem is 100% reproducible with a few clicks, after folding/unfolding a branch of the tree. But with the latests version, the crash will eventually occurs after a very quick succession of clicks on some Nodes (leaf or not). The stacktrace looks a bit different as well. I'm not sure if this is related to the same problem. Should I open a new bug report? Distinguishable mention of the app have been removed from the stacktrace below: Process: XXX [14839] Path: /Applications/XXX/XXX.app/Contents/MacOS/XXX Identifier: XXX Version: ??? (10.2) Code Type: X86-64 (Native) Parent Process: launchd [193] Date/Time: 2011-11-07 15:06:46.639 +0100 OS Version: Mac OS X 10.7.2 (11C74) Report Version: 9 Interval Since Last Report: 282804 sec Crashes Since Last Report: 17 Per-App Crashes Since Last Report: 6 Anonymous UUID: 33132B2F-A1B0-4F69-81C2-7D54A175F92D Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000000000000000d, 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Applications/XXX/XXX.app/Contents/MacOS/XXX Application Specific Information: objc[14839]: garbage collection is OFF Java information: Exception type: Bus Error (0xa) at pc=7fff8aa05333 Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02-383 mixed mode macosx-amd64) Current thread (104801000): JavaThread "main" [_thread_in_native, id=1908017504, stack(7fff5f400000,7fff5fc00000)] Stack: [7fff5f400000,7fff5fc00000] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.eclipse.swt.internal.cocoa.OS.object_getInstanceVariable(J[B[J)J J org.eclipse.swt.widgets.Display.getWidget(J)Lorg/eclipse/swt/widgets/Widget; j org.eclipse.swt.widgets.Tree.drawInteriorWithFrame_inView(JJLorg/eclipse/swt/internal/cocoa/NSRect;J)V+66 j org.eclipse.swt.widgets.Display.windowProc(JJJJ)J+188 v ~StubRoutines::call_stub j org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JLorg/eclipse/swt/internal/cocoa/NSRect;)J+0 j org.eclipse.swt.widgets.Widget.drawRect(JJLorg/eclipse/swt/internal/cocoa/NSRect;)V+91 J org.eclipse.swt.widgets.Display.windowProc(JJJ)J v ~StubRoutines::call_stub j org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJJJZ)J+0 j org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(JJJJJJ)J+77 j org.eclipse.swt.widgets.Display.applicationProc(JJJJJJ)J+93 v ~StubRoutines::call_stub j org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J+0 j org.eclipse.swt.widgets.Widget.callSuper(JJJ)V+32 j org.eclipse.swt.widgets.Widget.mouseDownSuper(JJJ)V+5 j org.eclipse.swt.widgets.Tree.mouseDownSuper(JJJ)V+349 j org.eclipse.swt.widgets.Widget.mouseDown(JJJ)V+5 j org.eclipse.swt.widgets.Control.mouseDown(JJJ)V+42 j org.eclipse.swt.widgets.Tree.mouseDown(JJJ)V+43 J org.eclipse.swt.widgets.Display.windowProc(JJJ)J v ~StubRoutines::call_stub j org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J+0 j org.eclipse.swt.widgets.Widget.callSuper(JJJ)V+32 j org.eclipse.swt.widgets.Widget.windowSendEvent(JJJ)V+5 j org.eclipse.swt.widgets.Shell.windowSendEvent(JJJ)V+585 J org.eclipse.swt.widgets.Display.windowProc(JJJ)J v ~StubRoutines::call_stub j org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;JJ)J+0 j org.eclipse.swt.widgets.Display.applicationSendEvent(JJJ)V+383 j org.eclipse.swt.widgets.Display.applicationProc(JJJ)J+107 v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJJ)J j org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(Lorg/eclipse/swt/internal/cocoa/NSEvent;)V+19 j org.eclipse.swt.widgets.Display.readAndDispatch()Z+113 j xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx()V+356 j xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx()V+81 j xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.main([Ljava/lang/String;)V+837 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;+161 j xxx.xxx.xxx.xxx.xxx.xxx([Ljava/lang/String;)V+146 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;+161 j apple.launcher.LaunchRunner.run()V+76 j apple.launcher.LaunchRunner.callMain()V+1 j apple.launcher.JavaApplicationLauncher.launch(JJZ)V+11 v ~StubRoutines::call_stub
I don't think this problem is fixed. I currently face a problem with JFace Databinding and 100 % cpu usage. The Java Visual VM leads me to the org.eclipse.swt.internal.cocoa.OS.objectorg.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper[native]() which hogs all the cpu time. This is with Indigo SR2 on OS X Lion. The DataBinding is employed as follows: IObservableValue txtMorningObserveTextObserveWidget = SWTObservables.observeText(txtMorning, SWT.Modify); IObservableValue curPrescrObservableCurrentPrescriptionSignaturedosageMorningObserveDetailValue = PojoObservables.observeDetailValue(curPrescrObservable, "currentPrescriptionSignature.dosageMorning", String.class); bindingContext.bindValue(txtMorningObserveTextObserveWidget, curPrescrObservableCurrentPrescriptionSignaturedosageMorningObserveDetailValue, null, null);
We have run into this issue as well with our Eclipse 3.6.1 RCP product.
Sorry, meant to say 3.7.1, so I echo the previous comments on the issue not fixed in 3.7.1.
This is our crash log: Process: TitaniumStudio [1113] Path: /Applications/Titanium Studio/TitaniumStudio.app/Contents/MacOS/TitaniumStudio Identifier: com.appcelerator.titanium Version: 3.0 (3.0) Code Type: X86 (Native) Parent Process: launchd [210] Date/Time: 2012-03-13 11:36:56.380 -0700 OS Version: Mac OS X 10.7.3 (11D50d) Report Version: 9 Interval Since Last Report: 138913 sec Crashes Since Last Report: 13 Per-App Interval Since Last Report: 63975 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: 38258DEF-C1A8-4771-8B7E-383AB48CA5BB ƒ Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000d5d5df73 VM Regions Near 0xd5d5df73: CG backing stores 00000000c563f000-00000000c61d4000 [ 11.6M] rw-/rw- SM=SHM --> Submap 00000000ffff0000-00000000ffff2000 r-x/r-x process-only submap Application Specific Information: objc[1113]: garbage collection is OFF Java information: Exception type: Bus Error (0xa) at pc=0000000097d22ce8 Java VM: Java HotSpot(TM) Client VM (20.4-b02-402 mixed mode macosx-x86) Current thread (0000000003921400): JavaThread "main" [_thread_in_native, id=-1395887424, stack(00000000bf800000,00000000c0000000)] Stack: [00000000bf800000,00000000c0000000] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.eclipse.swt.internal.cocoa.OS.object_getInstanceVariable(I[B[I)I J org.eclipse.swt.widgets.Display.GetWidget(I)Lorg/eclipse/swt/widgets/Widget; J org.eclipse.swt.widgets.Tree.drawInteriorWithFrame_inView(IILorg/eclipse/swt/internal/cocoa/NSRect;I)V j org.eclipse.swt.widgets.Display.windowProc(IIII)I+165 v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Lorg/eclipse/swt/internal/cocoa/objc_super;IIIIZ)I j org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(IIIIII)I+72 j org.eclipse.swt.widgets.Display.applicationProc(IIIIII)I+85 v ~StubRoutines::call_stub J org.eclipse.swt.internal.cocoa.OS.objc_msgSend(IIIIIZ)I J org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(ILorg/eclipse/swt/internal/cocoa/NSDate;Lorg/eclipse/swt/internal/cocoa/NSString;Z)Lorg/eclipse/swt/internal/cocoa/NSEvent; 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+555 j org.eclipse.ui.internal.Workbench.access$4(Lorg/eclipse/ui/internal/Workbench;)I+1 j org.eclipse.ui.internal.Workbench$7.run()V+55 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 com.appcelerator.titanium.rcp.IDEApplication.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+137 j org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/Object;)Ljava/lang/Object;+135 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;+161 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+211 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+126 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 v ~StubRoutines::call_stub
*** Bug 342005 has been marked as a duplicate of this bug. ***
Created attachment 243999 [details] Crash dump It looks like this hasn't been solved. We run into the same problem with SWT 4.3.2. See attached crash dump.
Created attachment 253488 [details] error dump crash on os x 10.x
