Description
Andrey Sobolev
2018-08-29 02:46:30 EDT
Created attachment 275597 [details]
Error log for java 8
Created attachment 275598 [details]
Error log for java 10
Hello everyone, I'm now getting the same error as Andrey after updating to the release version of Mojave today. The interesting fact is, that this does not appear if you are closing the lid and using a separate monitor. As soon as I'm using my MacBook open (with or without a connected monitor) running or debugging a application from Eclipse is not possible anymore. Thanks for your help! Regards, Yannic @Till: Can you help here? Same behaviour and crash with Eclipse Oxygen (4.7.3a). I cannot reproduce this using 4.7.3a or 4.9 with or without external monitor on macOS 10.14 (18A391) What java version are you using? Is the external monitor run in HiDPI? I'm not alone, this is good news at lest for me, I'm fight'ing with this issue since Mojave beta 1 for few months already. I've checked with/without monitor, but not checked with closed MacBook connected to external monitor. One interesting thing it is happening every time for Eclipse 4.7/4.8/4.9 ( Java 1.8/1.9/10) just on my Macbook Pro, but not with Macbook, so this is definitely something with Mojave, I've send feedback to Apple already about this, but no response as in most cases. My Macbook is on recovery, so will try in few days and write after upgrade to release version of Mojave. I've working with LG4k, same for both laptops. Java 1.8.131/1.8.181/10.0.1+10/ (In reply to Till Brychcy from comment #6) > I cannot reproduce this using 4.7.3a or 4.9 with or without external > monitor on macOS 10.14 (18A391) > What java version are you using? > Is the external monitor run in HiDPI? I'm using only the MBP monitor. Java version is 1.8.0_181, MacOS version is 18A391 (like yours) and Eclipse is Oxygen 3A (aka 4.7.3a). When running from Eclipse, it crashes immediately. When compiled and run as a stock macOS app, it works. Exact same error, MacBook Pro 2018, Mojave (macOS 10.14 (18A391)), both on Photon and 2018-09, java build 1.8.0_181-b13. (In reply to Mel T. from comment #10) > Exact same error, MacBook Pro 2018, Mojave (macOS 10.14 (18A391)), both on > Photon and 2018-09, java build 1.8.0_181-b13. I should add that I have no extra monitor. And that the built RCP app runs fine standalone. The crash occurs when starting in the IDE. Interesting question: why doesn't the main eclipse crash, but the nested one. Previously we had effects where this depended on what macOS sdk the main binary was linked against. Maybe it crashes for you, if you launch with java instead of the eclipse launcher. So one interesting question is: Does your main eclipse also crash if you start it from command line (Terminal) with java, e.g. /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/java -XstartOnFirstThread -jar /Applications/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.equinox.launcher_1.5.100.v20180827-1352.jar (this example is for eclipse 4.9 installed to /Applications - you need to adjust the path for it and for the java version and also the launcher version if you use another eclipse build) That's the same question which I'm asking myself. I tried to start Eclipse with java via the command line and it worked as aspected (used your command). Also I tried to start the target platform, which I want to start from Eclipse, directly via the command line (again using your command) and it also worked. I was able to choose my workspace and use the application as expected. So, if I'm using this way to start eclipse or the corresponding target platform I get no crashes. Can other users who have this problem attach a crash log (hs_err_pid?????.log), maybe having more samples allows us to narrow this down? Created attachment 275989 [details]
Crash log with Java 1.8.0_181, macOS Mojave 18A391, Eclipse 4.7.3a
Created attachment 275992 [details]
Crash log with Java 1.8.0_172, macOS 10.14 (18A391), Eclipse Photon I20180611-0500
Created attachment 275993 [details]
crash log
Created attachment 275994 [details]
Crash log with Java 10.0.0.2, macOS Mojave 18A391, Eclipse 4.9.0
I also checked if it's possible to run / debug a simple Java Class with 'Run as java application' as well as execute some PDE tests via 'JUnit Plug-in Test'. Both are working as expected. Hmm thanks for the extra dumps. Interesting: In the Java 10 dumps, the pc is shown as 0 (and no native frames are listed, but this may be related) I wonder if some object is released to early (or not retained though it should?) Please try running with the environment variable NSZombieEnabled set to YES is the launch configuration (see https://stackoverflow.com/questions/1324868/how-best-to-debug-a-crash-within-objc-msgsend) Unfortunately no success with the environment variable 'NSZombieEnabled' set to YES for me. Still getting the same error. I'm adding a new log with the variable set. Created attachment 275995 [details]
Crash log with Java 10.0.0.2, macOS Mojave 18A391, Eclipse 4.9.0, NSZombieEnabled=YES
(In reply to Yannic Soethoff from comment #22) > Created attachment 275995 [details] > Crash log with Java 10.0.0.2, macOS Mojave 18A391, Eclipse 4.9.0, > NSZombieEnabled=YES Hmm it looks like this somehow didn't work, this crash log doesn't show the environment variable, it only lists: [...] Environment Variables: PATH=/usr/bin:/bin:/usr/sbin:/sbin SHELL=/bin/bash Signal Handlers: [...] (In reply to Till Brychcy from comment #23) > Hmm it looks like this somehow didn't work, this crash log doesn't show the > environment variable, it only lists: Ok, I checked that and if I start the target platform (closed lid) with the environment variable defined I can find the variable set with the correct value in the "About -> Installation Details -> Configuration" tab. Within this section I can also find several other environment variables which are not included in the log too. [...] *** System environment variables: APP_ICON_5195=../Resources/Eclipse.icns Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.qN0sVAxjE3/Render HOME=/Users/d069676 JAVA_MAIN_CLASS_5473=org.eclipse.equinox.launcher.Main JAVA_STARTED_ON_FIRST_THREAD_5195=1 JAVA_STARTED_ON_FIRST_THREAD_5473=1 LOGNAME=d069676 NSZombieEnabled=YES PATH=/usr/bin:/bin:/usr/sbin:/sbin SHELL=/bin/bash SNC_LIB=/Applications/Secure Login Client.app/Contents/MacOS/lib/libsapcrypto.dylib SNC_LIB_64=/Applications/Secure Login Client.app/Contents/MacOS/lib/libsapcrypto.dylib SSF_LIBRARY_PATH=/Applications/Secure Login Client.app/Contents/MacOS/lib/libsapcrypto.dylib SSF_LIBRARY_PATH_64=/Applications/Secure Login Client.app/Contents/MacOS/lib/libsapcrypto.dylib SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.R8oNMKS4sX/Listeners TMPDIR=/var/folders/ns/jyvybyqx1fzfk89df9bsgyc80000gn/T/ USER=d069676 XPC_FLAGS=0x0 XPC_SERVICE_NAME=org.eclipse.platform.ide.2780 __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x3 [...] So maybe I'm doing something wrong. If so, can you please give me an advice how to do this? Thanks for checking. It looks like the crash dump only contains some specific env variables. Sorry for the confusion. Unfortunately that means that this settings doesn't lead to new information. Another idea to narrow this down: Can you launch SWT snippets (in the org.eclipse.swt.snippets project in the eclipse.platform.swt git repository) or do they crash in the same way? No problem! Unfortunately I have to disappoint you. I tested several snippets and all are working as expected. Given that closing the lid changes the behaviour: Does it make a difference if you tell the system to always use the discrete graphics processor (system preferences > energy saving (or something like that) > disable automatic card graphics switching)? Created attachment 276013 [details]
Crash log with Java 1.8.0_181, macOS Mojave 18A391, Eclipse 4.7.3a [Automatic switch of graphics card disabled]
Added an attachment containing the log with discrete graphic card always on. Does not seem to make a huge difference, unfortunately...
Is it maybe related to the touch bar that may be "off" when the lid is closed? (In reply to Matthias Becker from comment #29) > Is it maybe related to the touch bar that may be "off" when the lid is > closed? That is a very interesting idea: I cannot reproduce it and I use a macbook pro 2014 without touch bar. (In reply to Till Brychcy from comment #30) > (In reply to Matthias Becker from comment #29) > > Is it maybe related to the touch bar that may be "off" when the lid is > > closed? > > That is a very interesting idea: I cannot reproduce it and I use a macbook > pro 2014 without touch bar. Matthias, you are right! I can reproduce this now by enabling the touch bar simulator in XCode (Window > Show Touch Bar) I have a workaround: add -nosplash to the "Program arguments" in the launch configuration's "Arguments" tab. I confirm the workaround with "-nosplash" added to the Program Arguments. Thanks Till ! RCP App is now launching from Eclipse without a problem (albeit w/o splash screen). When the problem appears, the objective-c class of the instance returned by the NSApplication.sharedApplication-call in Display.createDisplay is not NSApplication, but NSKVONotifying_NSApplication. The code tries to change the type of the instance to the dynamically created subclass SWTApplication (using the OS.object_setClass call; this is called "isa swizzling" ) I came across some websites that mention that NSKVONotifying_* classes are used for "Key-value observing" and creating subclasses of these doesn't work. I too confirm that -nosplash is a good workaround for me too. (In reply to Till Brychcy from comment #32) > I have a workaround: add > -nosplash > to the "Program arguments" in the launch configuration's "Arguments" tab. The answer to this SO question suggests that method swizzling is needed instead of isa swizzling for KVO classes: https://stackoverflow.com/questions/11221110/my-isa-swizzling-breaks-kvo New Gerrit change created: https://git.eclipse.org/r/130110 (In reply to Eclipse Genie from comment #37) > New Gerrit change created: https://git.eclipse.org/r/130110 Actually it shouldn't matter if the touch bar software isn't notified about property changes of the application object, so the strategy in this simple patch is to use NSApplication explicitly as super class in this situation. (In reply to Till Brychcy from comment #38) > (In reply to Eclipse Genie from comment #37) > > New Gerrit change created: https://git.eclipse.org/r/130110 > > Actually it shouldn't matter if the touch bar software isn't notified about > property changes of the application object, so the strategy in this simple > patch is to use NSApplication explicitly as super class in this situation. BTW: Of course this is kind of hacky. This all being closed source, I can't guarantee that this doesn't break anything, but it is better than an immediate crash. In the end, we could just try it now and that future macOS releases don't break it. Alternatively, somebody could e.g. try to find a fix based on method swizzling if a KVO-class is detected. (In reply to Till Brychcy from comment #39) > just try it now and that future macOS releases don't break it. and >hope< that The reason for the crash has something to with the Splash. If you launch with "-nosplash" everything is OK. (In reply to Thomas Schindl from comment #41) > The reason for the crash has something to with the Splash. If you launch > with "-nosplash" everything is OK. yes, we know that already. See comment 32. (In reply to Thomas Schindl from comment #41) > The reason for the crash has something to with the Splash. If you launch > with "-nosplash" everything is OK. That is already written above :-) My guess is that the touch bar software installs some hook to add an value observer on the application object that is executed when the events for the splash screen are processed in Keywindow dispatch: (in eclipseCocoa.c). I have no idea why this only happens for a nested eclipse. Maybe Apple added some code to be compatible with SWT-based applications that doesn't get triggered in this Sitution? I more think PDE is the root of the problem because it reuses the the Eclipse executable currently running see "org.eclipse.pde.launching.EclipseApplicationLaunchConfiguration" (In reply to Thomas Schindl from comment #44) > I more think PDE is the root of the problem because it reuses the the > Eclipse executable currently running see > "org.eclipse.pde.launching.EclipseApplicationLaunchConfiguration" And this causes the class of the application object in the nested process to be changed to NSKVONotifying_NSApplication, because ...? BTW: you can copy the command line from the crashed process from its properties in the debug view and execute it in terminal and it'll crash, too. *** Bug 539867 has been marked as a duplicate of this bug. *** Hi, I am using SWT Application. prior to upgrade to MAC Mohave, application was working fine, but after upgrading to mohave, App is not launching. When I see the traces, libjvm is getting crashed. Stack: V libjvm::os::pd_print_crashinfo(outputStream*, void*)+0x48 (0x5df4cc) V libjvm::VMError::report(outputStream*)+0x296f (0x7f4f25) V libjvm::VMError::report_and_die()+0x774 (0x7fd39e) V libjvm::JVM_handle_bsd_signal+0x8b8 (0x5e2c25) V libjvm::javaSignalHandler(int, __siginfo*, void*)+0x34 (0x5dcd8f) C libsystem_platform::_sigtramp+0x1d (0x4b3d) C 0x00000a0c5bad9b6b+0xffffffff C Foundation::-[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:]+0x44 (0x19cd0) C Foundation::_NSSetObjectValueAndNotify+0xff (0x19c6a) C libswt-pi-cocoa-4530::Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJJ+0x36 (0xf2e9) C 0x000000010ae8e5c6+0xffffffff C 0x000000010ae77b90+0xffffffff C 0x000000010ae7807d+0xffffffff C 0x000000010ae7807d+0xffffffff C 0x000000010ae7807d+0xffffffff --------------- T H R E A D --------------- Current thread (0x00007fb5fa008000): JavaThread "main" [_thread_in_native (_running), id=775 [stack: 0x00007ffeedb00000,0x00007ffeee300000 (8192k)], stack: guarded I am using below maven dependency. <dependency> <groupId>org.eclipse.swt.org.eclipse.swt.cocoa.macosx.x86_64.4.3.swt</groupId> <artifactId>org.eclipse.swt.cocoa.macosx.x86_64</artifactId> <version>4.5</version> </dependency> (In reply to Hari Krishna Gurram from comment #48) [...] > C libsystem_platform::_sigtramp+0x1d (0x4b3d) > C 0x00000a0c5bad9b6b+0xffffffff > C Foundation::-[NSObject(NSKeyValueObservingPrivate) > _changeValueForKey:key:key:usingBlock:]+0x44 (0x19cd0) > C Foundation::_NSSetObjectValueAndNotify+0xff (0x19c6a) > [...] I don't see how this relates to the crash NSApplication.setDelegate, so you may want to file a separate bug. But your SWT version sounds old, so you may try to upgrade to the latest first, because I don't think investing your time to report bugs in unsupported old versions makes sense. The current version should be: <dependency> <groupId>org.eclipse.platform</groupId> <artifactId>org.eclipse.swt</artifactId> <version>3.108.0</version> </dependency> Hi Till, Thanks for the reply, but when using latest maven dependency, below package are not getting resolved. import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; Is it the right dependency for swt widgets ? Thanks, Hari (In reply to Hari Krishna Gurram from comment #50) > Hi Till, > Thanks for the reply, but when using latest maven dependency, below > package are not getting resolved. > > import org.eclipse.swt.*; > import org.eclipse.swt.widgets.*; > > Is it the right dependency for swt widgets ? > > Thanks, > Hari You should be able to specify the target via the osgi.platform property, but it looks like this doesn't work. Anyway, this is off-topic for this bug, so please create a fresh one. (I'll set these comment to obsolete to hide them) Will the workaround -nosplash argument work for standalone SWT applications not RCP ? Best Regards, Saurav What about the Gerrit Patch. Any Plans to merge it before the next releasee? Gerrit change https://git.eclipse.org/r/130110 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6b498d085fe2e1e0f03402782ee7c8203d9d2202 (In reply to Eclipse Genie from comment #54) > Gerrit change https://git.eclipse.org/r/130110 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=6b498d085fe2e1e0f03402782ee7c8203d9d2202 Released for 4.10M3 (In reply to Till Brychcy from comment #55) > (In reply to Eclipse Genie from comment #54) > > Gerrit change https://git.eclipse.org/r/130110 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=6b498d085fe2e1e0f03402782ee7c8203d9d2202 > > Released for 4.10M3 Thank you Till! Thanks for the fix Till! Verified with I20181119-2315 I am currently experiencing this same issue on my MacBookPro16 with Mac OS 10.15 .3 when launching from IDE - Eclipse 4.14.0. Yes the -nosplash Program Argument is a workaround for me as well but I was under the impression/understanding this was fixed in 4.10 M3. Should I create a new bug? MY SYSTEM CONFIG: ----------------- Eclipse IDE for RCP and RAP Developers Version: 2019-12 (4.14.0) Build id: 20191212-1212 System Software Overview: System Version: macOS 10.15.3 (19D76) Kernel Version: Darwin 19.3.0 Boot Volume: Macintosh HD Boot Mode: Normal Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro16,1 Processor Name: 8-Core Intel Core i9 Processor Speed: 2.3 GHz Number of Processors: 1 Total Number of Cores: 8 L2 Cache (per Core): 256 KB L3 Cache: 16 MB Hyper-Threading Technology: Enabled Memory: 16 GB Boot ROM Version: 1037.80.53.0.0 (iBridge: 17.16.13050.0.0,0) Here is my stack frame trace from hr_err*.log: Stack: [0x00007ffee0db4000,0x00007ffee15b4000], sp=0x00007ffee15af080, free space=8172k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libobjc.A.dylib+0x1107d] -[NSObject superclass]+0x11 C [libswt-pi-cocoa-4880.jnilib+0xff7d] Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJ+0x2d j org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJ)J+0 j org.eclipse.swt.widgets.Display.finishLaunching(JJ)V+32 j org.eclipse.swt.widgets.Display.applicationProc(JJ)J+79 v ~StubRoutines::call_stub V [libjvm.dylib+0x2eab0e] V [libjvm.dylib+0x321820] V [libjvm.dylib+0x319a12] C [libswt-cocoa-4880.jnilib+0x2826] callback+0x536 C [libswt-cocoa-4880.jnilib+0x5143] fn0_2+0x23 C [libswt-pi-cocoa-4880.jnilib+0xff7d] Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJ+0x2d j org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJ)J+0 j org.eclipse.swt.internal.cocoa.NSApplication.finishLaunching()V+7 j org.eclipse.swt.widgets.Display.init()V+113 j org.eclipse.swt.graphics.Device.<init>(Lorg/eclipse/swt/graphics/DeviceData;)V+168 j org.eclipse.swt.widgets.Display.<init>(Lorg/eclipse/swt/graphics/DeviceData;)V+2 j org.eclipse.swt.widgets.Display.<init>()V+2 j org.eclipse.ui.internal.Workbench.createDisplay()Lorg/eclipse/swt/widgets/Display;+81 j org.eclipse.ui.PlatformUI.createDisplay()Lorg/eclipse/swt/widgets/Display;+0 j com.worldpac.pde.application.Application.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+0 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;+85 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/lang/Object;)Ljava/lang/Object;+82 j org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/Object;)Ljava/lang/Object;+105 j org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/String;Ljava/lang/Runnable;)Ljava/lang/Object;+132 v ~StubRoutines::call_stub V [libjvm.dylib+0x2eab0e] V [libjvm.dylib+0x4caf44] V [libjvm.dylib+0x4cb478] V [libjvm.dylib+0x342cc0] 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;+100 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;+56 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+205 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+160 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 j org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10 v ~StubRoutines::call_stub V [libjvm.dylib+0x2eab0e] V [libjvm.dylib+0x321820] V [libjvm.dylib+0x31a59a] C [java+0x393e] JavaMain+0x9b1 C [java+0x559c] -[JavaLaunchHelper launchJava:]+0x2a C [Foundation+0x9c8ab] __NSThreadPerformPerform+0xfe C [CoreFoundation+0x84b21] __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x11 C [CoreFoundation+0x84ac0] __CFRunLoopDoSource0+0x67 C [CoreFoundation+0x848d4] __CFRunLoopDoSources0+0xd1 C [CoreFoundation+0x83740] __CFRunLoopRun+0x4f8 C [CoreFoundation+0x82bd3] CFRunLoopRunSpecific+0x1f3 C [java+0x6463] CreateExecutionEnvironment+0x367 C [java+0x21ac] JLI_Launch+0x7a0 C [java+0x84c0] main+0x65 C [java+0x1a04] start+0x34 C 0x0000000000000026 I am sorry I posted the wrong stack frame. This is the frame corresponding to jvm crash: Stack: [0x00007ffee7602000,0x00007ffee7e02000], sp=0x00007ffee7dfd278, free space=8172k Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJJ)J+0 j org.eclipse.swt.internal.cocoa.NSApplication.setDelegate(Lorg/eclipse/swt/internal/cocoa/id;)V+19 j org.eclipse.swt.widgets.Display.init()V+100 j org.eclipse.swt.graphics.Device.<init>(Lorg/eclipse/swt/graphics/DeviceData;)V+168 j org.eclipse.swt.widgets.Display.<init>(Lorg/eclipse/swt/graphics/DeviceData;)V+2 j org.eclipse.swt.widgets.Display.<init>()V+2 j org.eclipse.ui.internal.Workbench.createDisplay()Lorg/eclipse/swt/widgets/Display;+81 j org.eclipse.ui.PlatformUI.createDisplay()Lorg/eclipse/swt/widgets/Display;+0 j com.worldpac.pde.application.Application.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+0 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;+85 j org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/lang/Object;)Ljava/lang/Object;+82 j org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/Object;)Ljava/lang/Object;+105 j org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/String;Ljava/lang/Runnable;)Ljava/lang/Object;+132 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;+100 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;+56 j org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+205 j org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+160 j org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4 j org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10 v ~StubRoutines::call_stub If the problem reappears on 10.15, please create a fresh bug and also mention your java version, which might make a difference. (But I personally currently cannot analyze this in the near future, as I don't have any Mac with 10.15 because of its lack of 32-bit support) Hi I can confirm same problem, macOS 15.3, Eclipse RCP platform (2019-12). I tried initially with a number of different JRE's and versions of JRE's until I found this bug report. Workaround with -nosplash works also here. Per Till's recommendation I created Bug 560364. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168518 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168906 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168906 was merged to [R4_8_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d682722fc78fee71f6bc773ebd50449bc4550f70 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168518 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8f398cb6f40bc02560ea6fafa9cdc59cb60271e7 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178117 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178117 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=51058aafe04e9ddf73eb8929e98359d9a9c1ac97 Perhaps related, on macOS 10.15 I get this with the latest Eclipse 4.21 using its embedded VM when I close a tree item in the Navigator: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff2031e92e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff2034d5bd pthread_kill + 263 2 libsystem_c.dylib 0x00007fff202a2406 abort + 125 3 libjvm.dylib 0x000000000f6b13c1 os::abort(bool, void*, void const*) + 49 4 libjvm.dylib 0x000000000f894248 VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) + 2984 5 libjvm.dylib 0x000000000f893675 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) + 149 6 libjvm.dylib 0x000000000f8942e1 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) + 33 7 libjvm.dylib 0x000000000f75d4b9 JVM_handle_bsd_signal + 265 8 libsystem_platform.dylib 0x00007fff20392d7d _sigtramp + 29 9 ??? 0xaaaaaaaaaaaaaaaa 0 + 12297829382473034410 10 com.apple.Foundation 0x00007fff2117861d -[NSConcreteMapTable objectForKey:] + 62 11 com.apple.AppKit 0x00007fff22d7ba72 -[NSOutlineView rowForItem:] + 75 12 libswt-pi-cocoa-4946r21.jnilib 0x0000000016faca45 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJJ + 53 13 ??? 0x0000000020383b68 0 + 540556136 14 ??? 0x000000002143b064 0 + 558084196 Process: eclipse Path: /Users/USER/*/Eclipse.app/Contents/MacOS/eclipse Identifier: org.eclipse.platform.ide Version: 4.21.0 (4.21.0.I20210830-0600) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: eclipse OS Version: macOS 11.5.2 (20G95) |