Community
Participate
Working Groups
Created attachment 279871 [details] Javacore log file Hello, I use OpenJ9 JVM (from AdoptJDK) on my x64 Win7 computer. This was working on Eclipse 4.12 but it does not work anymore on 4.13 RC1. I tried: - jdk8u202-b08 : Crash - jdk-11.0.3+7 : Crash - jdk-11.0.4+11 : Crash while it works with hotspot (jdk-11.0.4+11 provided by AdoptJDK). Attach is my javacore log file. I'll use hotspot unfortunately waiting for a solution. Thanks. -- Fin~
Hmm.. all I see is a memory allocation failure, which I don't see being related to JDT Core, or Eclipse for that matter. So, Fin, just to double check, you used the exact version of OpenJ9 JVM with 4.12 and it worked?
I met the same isssue in Eclipse CDT 2019-09 offical release. The J9VM jdk8u222-b10 works fine it in Eclipse 4.11(2019-03) but crashed in Eclipse 4.13.
My PC is also x64 Win7 computer, i5-6500@3.20GHz 16G RAM
It seems strange that path in HOOK subcomponent dump routine section of the log file "C:\cygwin64\tmp\openjdk-jdk8u-windows-x64-openj9\workspace\build\src\build\windows-x86_64-normal-server-release..." not exist on my PC. It cound be found in log file attched by Fin (Only jdk8u replaced by jdk11u)
(In reply to Jay Arthanareeswaran from comment #1) > Hmm.. all I see is a memory allocation failure, which I don't see being > related to JDT Core, or Eclipse for that matter. > > So, Fin, just to double check, you used the exact version of OpenJ9 JVM with > 4.12 and it worked? Hello, Yes, I was working on 4.12 with openJ9 I made update to 4.13 and it crashed at startup. Now, I just made - clean install of 4.12 for Java dev (eclipse-java-2019-06-R-win32-x86_64) - new workspace - works with openJ9 Then - clean install of 4.13 for Java dev (eclipse-java-2019-09-R-win32-x86_64) - new workspace - crash with openJ9 - works with hotspot JVM's from AdoptOpenJDK: jdk-11.0.4+11 with openj9-0.15.1 jdk-11.0.4+11 with hotspot And finally, Yes, The problem may be related to OpenJ9 and not core/Eclipse, yet, for you to know the changes made on Eclipse side for this new 4.13 version do not allow my machine at least to work using OpenJ9. Thanks ! -- Fin'~
Does anybody have any indication that this crash is Eclipse's fault? Frankly, I'm not sufficiently familiar with OpenJ9's dump format to even find any problem in that log. Has a bug been filed against the crashing system, OpenJ9?
I filled a report on OpenJ9 tracker and added additional files: - jit dump - core dump https://github.com/eclipse/openj9/issues/7204 hope this can help. Thanks. -- Fin'~
Looks like SWT / Mylin issue, probably related to bug 548457 changes. 1XHEXCPMODULE Module: D:\Softwares\eclipse\configuration\org.eclipse.osgi\445\0\.cp\swt-win32-4928r15.dll 1XMCURTHDINFO Current thread 3XMTHREADINFO "main" J9VMThread:0x00000000004BB100, omrthread_t:0x00000000004492B0, java/lang/Thread:0x000007FFC007E538, state:R, prio=6 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x22F0, native priority:0x6, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00000020) 3XMCPUTIME CPU usage total: 13.119684100 secs, user: 10.920070000 secs, system: 2.199614100 secs, current category="Application" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=12478232 (0xBE6718) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at org/eclipse/swt/internal/ole/win32/COM.VtblCall(Native Method) 4XESTACKTRACE at org/eclipse/swt/internal/ole/win32/IUnknown.Release(IUnknown.java:32) 4XESTACKTRACE at org/eclipse/swt/widgets/TaskBar.setMenu(TaskBar.java:429) 4XESTACKTRACE at org/eclipse/swt/widgets/TaskItem.setMenu(TaskItem.java:255) 4XESTACKTRACE at jdk/internal/reflect/NativeMethodAccessorImpl.invoke0(Native Method) 4XESTACKTRACE at jdk/internal/reflect/NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 4XESTACKTRACE at jdk/internal/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Method.invoke(Method.java:566(Compiled Code)) 4XESTACKTRACE at org/eclipse/mylyn/commons/workbench/TaskBarManager$TaskBarMenuManager.setMenuOnTaskItem(TaskBarManager.java:120) 4XESTACKTRACE at org/eclipse/mylyn/commons/workbench/TaskBarManager$TaskBarMenuManager.update(TaskBarManager.java:111) 4XESTACKTRACE at org/eclipse/jface/action/MenuManager.update(MenuManager.java:672) 4XESTACKTRACE at org/eclipse/mylyn/internal/tasks/ui/TasksUiPlugin.addSystemTaskBarActions(TasksUiPlugin.java:476) 4XESTACKTRACE at org/eclipse/mylyn/internal/tasks/ui/TasksUiPlugin.access$7(TasksUiPlugin.java:455) 4XESTACKTRACE at org/eclipse/mylyn/internal/tasks/ui/TasksUiPlugin$TasksUiInitializationJob.runInUIThread(TasksUiPlugin.java:391)
Finway: please try to start a fresh 4.13 SDK installation (that does NOT contain Mylyn) that you can get from this link: https://download.eclipse.org/eclipse/downloads/.
(In reply to Andrey Loskutov from comment #8) > Looks like SWT / Mylin issue, probably related to bug 548457 changes. Or related to bug 548384 changes, or to both.
(In reply to Andrey Loskutov from comment #9) > Finway: please try to start a fresh 4.13 SDK installation (that does NOT > contain Mylyn) that you can get from this link: > https://download.eclipse.org/eclipse/downloads/. I confirm that SDK version is working with same OpenJ9 JVM (jdk-11.0.4+11 with openj9-0.15.1) Version: 2019-09 (4.13) Build id: I20190916-1045
I have absolutely no knowledge about SWT code, but this is highly suspicious: Taskbar.java, line 429 calls "poa.release()" _inside a loop_ that iterates over the menu items contained in "poa". I assume "poa.release()" needs to be moved 1 line down, outside the loop.
New Gerrit change created: https://git.eclipse.org/r/150597
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/150597 Because of following reason we consider it for 4.14 M1: - A regression from bug 548457 - Crash scenario - Fix is simple Nikita: Please verify the patch and release to master.
Gerrit change https://git.eclipse.org/r/150597 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a35a9787b3ab2b7e283cf31b7342a7e5d721e7a4
Thanks to everyone who investigated the problem and Michael for fixing it.
*** Bug 552407 has been marked as a duplicate of this bug. ***
