Community
Participate
Working Groups
Second crash in two days. Using 64-bit Cocoa. Process: eclipse [9938] Path: /Users/USER/*/Eclipse.app/Contents/MacOS/eclipse Identifier: org.eclipse.sdk.ide Version: 4.3.1 (4.3.1.M20130911-1000) Code Type: X86-64 (Native) Parent Process: launchd [128] User ID: 501 Date/Time: 2013-11-22 15:46:04.372 -0500 OS Version: Mac OS X 10.8.5 (12F37) Report Version: 10 Interval Since Last Report: 2500069 sec Crashes Since Last Report: 122 Per-App Interval Since Last Report: 63046 sec Per-App Crashes Since Last Report: 2 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Application Specific Information: Java information: Exception type: Bus Error (0xa) at pc=7fff8dfbcdac Java VM: Java HotSpot(TM) 64-Bit Server VM (20.51-b01-457 mixed mode macosx-amd64) Current thread (107800800): JavaThread "main" [_thread_in_native, id=2091598208, 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.Display.getWidget(J)Lorg/eclipse/swt/widgets/Widget;+1 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;JJJJZ)J 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_msgSend(JJJJJZ)J j org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(JLorg/eclipse/swt/internal/cocoa/NSDate;Lorg/eclipse/swt/internal/cocoa/NSString;Z)Lorg/eclipse/swt/internal/cocoa/NSEvent;+36 j org.eclipse.swt.widgets.Display.readAndDispatch()Z+98 J org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.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;+57 j org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(Lorg/eclipse/e4/ui/model/application/MApplicationElement;)V+20 j org.eclipse.ui.internal.Workbench$5.run()V+236 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;+108 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;+119 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 ... VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap par new generation total 59968K, used 38679K [7b0000000, 7b4110000, 7b8000000) eden space 53312K, 72% used [7b0000000, 7b25c5c68, 7b3410000) from space 6656K, 0% used [7b3410000, 7b3410000, 7b3a90000) to space 6656K, 0% used [7b3a90000, 7b3a90000, 7b4110000) concurrent mark-sweep generation total 464280K, used 266408K [7b8000000, 7d4566000, 7f0000000) concurrent-mark-sweep perm gen total 262144K, used 194638K [7f0000000, 800000000, 800000000) Code Cache [108001000, 109c62000, 10b001000) total_blobs=6777 nmethods=5991 adapters=743 free_code_cache=21062080 largest_free_block=47296 Virtual Machine Arguments: JVM Args: -Xms40m -Xmx1024m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=256m Java Command: <unknown> Launcher Type: generic Physical Memory: Page Size = 4k, Total = 8192M, Free = 2484M
Please provide any steps which can be used to reproduce the crash. Did you start seeing the crashes only with Eclipse 4.3.1 or did it happen even with 4.3? Can you try with a different/new workspace and see if the crashes continue to occur?
*** Bug 424764 has been marked as a duplicate of this bug. ***
Created attachment 239855 [details] Patch initializing Instance Variables for cell
I can reproduce the crash by doing expand and collapse of root node on big tree (hundreads of nodes) where nodes are changed/updated on background during the expand/collapse. I think the crash happend in Tree.drawInteriorWithFrame_inView method running OS.object_getInstanceVariable(id, Display.SWT_ROW, outValue), when Display.SWT_ROW was previously NOT set by OS.object_setInstanceVariable(...). In some cases when this situation happens the 'Display.SWT_ROW' variable on native C/C++ side is not initialized and may contain some random value causing crash when this value is retrieved by OS.object_getInstanceVariable. To solve the problem I initialize the content to zero when object is created. I do so in Tree.createHandle() method right after 'dataCell' variable is initialized I added following two lines: OS.object_setInstanceVariable(dataCell.id, Display.SWT_ROW, 0l); OS.object_setInstanceVariable(dataCell.id, Display.SWT_COLUMN, 0l); See my 'Patch initializing Instance Variables for cell' attachment. Sorry for wrong patch format of my attachment. It's just plain version of changed Tree.java file.
*** Bug 429527 has been marked as a duplicate of this bug. ***
Abhishek, can you please investigate this crash? Milan, is it possible for you to upload a snippet of code that you used to reproduce the crash? It will really help in providing a fix faster. Thanks!
Randy and Milan, We would like to have this crash fixed in Luna but we cannot investigate the problem and test the provided patch without being able to reproduce the problem at our end. Please provide a snippet of code or steps that can be used in Eclipse to reproduce this crash. Thanks!
I was not able to create simple snippet to repreoduce the issue. I can only describe how I reproduce the issue on Toad Extension for Eclipse (TEE). It's free plug-in for Eclipse and can be installed using Marketplace. Some sample Oracle database is needed to reproduce the issue using TEE. Steps to reprodue: * Install TEE * Switch to 'Toad Extension' Perspective * Connect to sample Oracle database using 'New Connection' drop-down button in Connections view * Open 'All Schemas' tree node in 'Object Explorer' view (it should be a big tree) * Open several sub-notes of 'All Schemas' (and some sub-sub nodes, etc.) to get a realy big tree. * Collapse and expand 'All Schemas' node several times. Eclipse will crash. I tried to make some snippet which works similary as tree in TEE, but I wasn't able to reproduce the crash on it. The only way I can reproduce the crash using TEE.
*** Bug 417302 has been marked as a duplicate of this bug. ***
Niraj, https://git.eclipse.org/r/28728 - for your review. I am unable to recreate the issue, but changes suggested in comment 4 make sense to me.
This consistently happens for me using our product built on top of Eclipse. Currently I am running the following build and am willing to try a patched JAR to test it if you like. Version: Luna SR1 (4.4.1) Build id: M20140723-0800
Created attachment 246692 [details] crash report I tried running a patched JAR containing the fix but it still crashed for me when expanding/collapsing the Tree view while it was being updated in a background thread. I've attached another crash report.
I hit this issue everyday and it continues to become increasingly frustrating. I haven't been able to come up with a stand-alone test case yet, but can give you instructions on how to easily reproduce it using our product if you wish.
(In reply to DJ Houghton from comment #13) > I hit this issue everyday and it continues to become increasingly > frustrating. > > I haven't been able to come up with a stand-alone test case yet, but can > give you instructions on how to easily reproduce it using our product if you > wish. Please provide the necessary steps and we'll try to investigate further. (In reply to Milan Vahala from comment #4) > I can reproduce the crash by doing expand and collapse of root node on big > tree (hundreads of nodes) where nodes are changed/updated on background > during the expand/collapse. > > See my 'Patch initializing Instance Variables for cell' attachment. Milan, does the attached patch prevent the crash from happening for you?
Yes, the patch prevents the crash from happening. DJ Houghton send the instructions how to reproduce the crash on your product, please so we can find out why the patch doesn't work in your case.
I am communicating with Arun via email as the instructions include internal downloads and servers.
Created attachment 246930 [details] Example plug-in demonstrating the problem. I've attached an example plug-in which demonstrates the problem. - The plug-in creates a simple tree view and keeps populating it with nodes. - One thread gets a random node, changes the label, adds a child, and refreshes the tree. - Another thread gets a random node from the tree and expands its children. To get the crash open up the view and it will start populating and expanding automatically. Randomly select nodes and collapse them (either keyboard or mouse will work) and eventually it will crash.
(I ran this test case on Eclipse 4.5)
Did the attached sample help? Were you able to reproduce the issue locally?
Example plug-in works fine, I'm able to reproduce crash every time. Crash happens in Tree.drawInteriorWithFrame_inView(…) method in following line: TreeItem item = (TreeItem) display.getWidget (outValue [0]); I logged content of outValue[0] before display.getWidget(outValue[0]). I also logged content of 'id' parameter in TreeItem.dealloc(…) method. In these logs I can see that outValue[0] causing the crash (the last one before crash) was already deallocated in TreeItem.dealloc(…) method. This can be the reason of the crash. The solution is to call display.removeWidget(handle) in TreeItem.deregister() method which is commented out with note 'This is done in #dealloc'. I suggest to call 'if (handle != null) display.removeWidget(handle);' in TreeItem.deregister() method. There also may be possible to remove 'OS.object_setInstanceVariable(id, Display.SWT_OBJECT, 0);' from TreeItem.dealloc(…) method.
(In reply to Milan Vahala from comment #20) > Example plug-in works fine, I'm able to reproduce crash every time. > > Crash happens in Tree.drawInteriorWithFrame_inView(…) method in following > line: > TreeItem item = (TreeItem) display.getWidget (outValue [0]); > > I logged content of outValue[0] before display.getWidget(outValue[0]). I > also logged content of 'id' parameter in TreeItem.dealloc(…) method. In > these logs I can see that outValue[0] causing the crash (the last one before > crash) was already deallocated in TreeItem.dealloc(…) method. This can be > the reason of the crash. > > The solution is to call display.removeWidget(handle) in > TreeItem.deregister() method which is commented out with note 'This is done > in #dealloc'. I suggest to call 'if (handle != null) > display.removeWidget(handle);' in TreeItem.deregister() method. There also > may be possible to remove 'OS.object_setInstanceVariable(id, > Display.SWT_OBJECT, 0);' from TreeItem.dealloc(…) method. The dealloc in TreeItem.deregister() was added as part of the fix for Bug 380966. The bug was a similar looking crash...
We attempted to fix this problem some time back (see Bug 326311). The changes in the bug did fix the problem with our testcase. But, looks like the problem was not fixed completely. Will upload a patch that fixes the problem in Tree.drawInteriorWithFrame_inView().
Created attachment 247189 [details] patch Tested the patch with the example plug-in, it fixes the crash.
I tested the patch as well and it fixes the issue in my use case. Thanks!
Given that this is critical, any chance of getting it into 4.4.1? 4.4.2? Or, lastly, a 4.4.1-based patch attached to this WI (JAR file)?
(In reply to Randy Hudson from comment #25) > Given that this is critical, any chance of getting it into 4.4.1? 4.4.2? > Or, lastly, a 4.4.1-based patch attached to this WI (JAR file)? Its too late to fix this for 4.4.1 but it will definitely be fixed in 4.4.2...
Pushed patch to 4.5 master --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e90ab2125687aa309a4ccb3b915236a2c38bbe42
The fix delivered to the 4.5 stream seemed pretty minor. Is the fix in 4.4.2 more involved? When will this go in?
Fixed in R4_4_maintenance branch --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_4_maintenance&id=f98c59435570596b1a2dc71d45e34aa708d783a0
(In reply to Randy Hudson from comment #28) > The fix delivered to the 4.5 stream seemed pretty minor. Is the fix in > 4.4.2 more involved? When will this go in? The fix for 4.5 and 4.4.2 is the same. We wanted to make sure the fix in master is tested for a while before pushing it to maintenance branch.
Awesome!
Verified in build: M20150128-1000
*** Bug 388814 has been marked as a duplicate of this bug. ***
