Community
Participate
Working Groups
Build Identifier: 20100917-0705 Mac OS Cocoa 64-Bit Eclipse keeps crashing very often (ususaly within a few minutes up to aprox. an our after starting it). There's no apparent reason for this, it may happen while checking out Sources from SVN, executing Maven Builds or even while clicking in the Project Explorer or opening the project settings. Java Version: java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode) Reproducible: Always Steps to Reproduce: none, it happens randomly.
Created attachment 187866 [details] workbench log
Created attachment 187867 [details] Crash Dump
Created attachment 187868 [details] Workbench Configuration
(In reply to comment #2) > Created attachment 187867 [details] > Crash Dump Crash seems to happen in native code. Moving to SWT. Current thread (114000800): JavaThread "main" [_thread_in_native, id=1885002784, stack(7fff5f400000,7fff5fc00000)] Stack: [7fff5f400000,7fff5fc00000] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJLorg/eclipse/swt/internal/cocoa/NSRect;Z)J+0 j org.eclipse.swt.internal.cocoa.NSWindow.setFrame(Lorg/eclipse/swt/internal/cocoa/NSRect;Z)V+9 j org.eclipse.swt.widgets.Shell.setBounds(IIIIZZ)V+391 j org.eclipse.swt.widgets.Control.setBounds(IIII)V+20 j org.eclipse.jface.dialogs.TrayDialog.closeTray()V+170
I have been working with the 32-bit Version for a couple of hours: Same plugins, same projects and no crashes at all. This seems to be a Cocoa 64-bit problem only.
I haven't tried 3.6.1 x86_64 explicitly yet, but do you know if this bug reproduces in 3.7? Right now it looks like a native null pointer, but I'm not sure how it's happening.
Turns out this is very easy to reproduce by showing the help content on the run configuration dialog, and then clicking the Close button with the help visible. On 3.6.1 (and 3.6.2) 64-bit I crash every time with the stack trace shown here. However, on 3.7 HEAD I can't reproduce it at all. The only change I can find between HEAD and 3.6.1 that seems related is bug 325607, but even that seems tenuous at best. I need to track down an NPE I'm seeing in 3.6.2's SWT, but I need to download a full 3.6.2 to do that.
(In reply to comment #7) > I need to track down an NPE I'm seeing in 3.6.2's SWT, but I need to download a > full 3.6.2 to do that. The NPE is happening because an Image used by a Label in the TrayDialog has been disposed, but the label itself has not. The call to Shell.setBounds() leads to a call back in the SWT that is re-laying out the dialog, and eventually we try to get the size of the image but can't. The build ID is M20110202-0800. It's odd that this only triggers an NPE in 32-bit but crashes in 64-bit. I'm going to check the actual 32-bit build just to be safe, because I tested in a self-hosted setup. Either way, passing over to UI for more comment.
In M20110202-0800 32-bit Cocoa, the IDE is hung when the exception is triggered, probably due to something like 331771. An exception thrown during call-in to the SWT leaves JNI unable to function.
The NPE from the TrayDialog is has been fixed with bug 333684 (but the fix needs rework, see bug 333684). Moving back to SWT to handle the native NPE more gracefully (with TrayDialog 1.11).
(In reply to comment #10) > Moving back to SWT to handle the native NPE more gracefully (with TrayDialog > 1.11). The crash is fixed in HEAD with the change for 321218, and was fixed in HEAD after we branched for 3.6.1. This now makes sense -- there's an attempt to call [NSException raise] to propagate back the NPE, but it's killing the application. I'm not sure if we can get that change into 3.6.2 at this point. *** This bug has been marked as a duplicate of bug 321218 ***
Created attachment 188478 [details] Patch for 3.6 branch Although we won't be fixing this in the 3.6.2 stream, if someone is running into this and it's blocking a release, this patch can be used against the R3_6_maintenance branch to build an SWT that won't crash and will dump the java exception.
