Bug 326311

Comment 1 Boris Bokowski 2010-09-27 10:45:03 EDT

Created attachment 179652 [details]
thread dump

Comment 2 Lakshmi P Shanmugam 2011-03-03 06:51:45 EST

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

Comment 3 Scott Kovatch 2011-03-03 11:44:33 EST

I _think_ this just needs an isDisposed() check at the beginning of Tree#expandItem_expandChildren. It's hard to reproduce though.

Comment 4 Lakshmi P Shanmugam 2011-05-17 09:30:07 EDT

I'm investigating this for RC2.

Comment 5 Lakshmi P Shanmugam 2011-06-22 09:13:42 EDT

Created attachment 198397 [details]
snippet to reproduce crash

Expanding or Collapsing a tree node just when it is disposed causes the crash.

Comment 6 Lakshmi P Shanmugam 2011-08-17 11:06:03 EDT

Created attachment 201650 [details]
patch

The patch checks if the item is disposed before calling display.getWidget().
Silenio, please review for 3.7.1.

Comment 7 Lakshmi P Shanmugam 2011-08-17 11:15:13 EDT

Created attachment 201651 [details]
patch-2

Comment 8 Lakshmi P Shanmugam 2011-08-17 11:24:29 EDT

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

Comment 9 Silenio Quarti 2011-08-17 12:29:45 EDT

Lakshmi, this patch does not apply properly using  menu "Eclipse -> Team -> Apply Path".  How did you generate it?

Comment 10 Lakshmi P Shanmugam 2011-08-17 12:52:01 EDT

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.

Comment 11 Silenio Quarti 2011-08-17 14:17:16 EDT

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?

Comment 12 Lakshmi P Shanmugam 2011-08-17 15:36:06 EDT

(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.

Comment 13 Silenio Quarti 2011-08-22 15:18:38 EDT

Lakshmi, did you have a chance to test my patch? Should we release it to 3.7.1 and 3.8?

Comment 14 Lakshmi P Shanmugam 2011-08-23 08:05:28 EDT

(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.

Comment 15 Silenio Quarti 2011-08-23 11:16:24 EDT

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

Comment 16 Marc H. Marc H. 2011-11-07 09:40:25 EST

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

Comment 17 Marco Descher 2012-02-29 04:03:42 EST

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);

Comment 18 Michael Xia 2012-03-13 18:54:46 EDT

We have run into this issue as well with our Eclipse 3.6.1 RCP product.

Comment 19 Michael Xia 2012-03-13 18:55:33 EDT

Sorry, meant to say 3.7.1, so I echo the previous comments on the issue not fixed in 3.7.1.

Comment 20 Michael Xia 2012-03-13 18:58:25 EDT

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

Comment 21 Lakshmi P Shanmugam 2012-08-06 03:23:52 EDT

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

Comment 22 Carl Hasselskog 2014-06-05 10:38:18 EDT

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.

Comment 23 bob Wen 2015-05-14 22:33:46 EDT

Created attachment 253488 [details]
error dump

crash on os x 10.x