Community
Participate
Working Groups
Created attachment 282750 [details] Crash log from the error on start-up. To reproduce, I add the following to the eclipse.ini: -vm /usr/lib/jvm/java-11-openjdk-11.0.5.10-0.el7_7.x86_64-debug/bin/java (path should vary) Then I start Eclipse on the command line with: export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.5.10-0.el7_7.x86_64-debug/ && ./eclipse This results in a reproducible crash on start-up (see attached "hs_err_pid79084.log"): [24.874s][warning][malloc,free] ## nof_mallocs = 752508, nof_frees = 150203 [24.874s][warning][malloc,free] ## memory stomp: [24.874s][warning][malloc,free] GuardedMemory(0x00007ffff7fcb2f0) base_addr=0x00007ffff0c01b40 tag=0x0000000000000000 user_size=1 user_data=0x00007ffff0c01b60 [24.874s][warning][malloc,free] Header guard @0x00007ffff0c01b40 is OK [24.874s][warning][malloc,free] Trailer guard @0x00007ffff0c01b61 is BROKEN [24.874s][warning][malloc,free] User data appears to be in use # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:638 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/builddir/build/BUILD/java-11-openjdk-11.0.5.10-0.el7_7.x86_64/openjdk/src/hotspot/share/runtime/os.cpp:638), pid=79084, tid=79085 # fatal error: memory stomping error # # JRE version: OpenJDK Runtime Environment (11.0.5+10) (slowdebug build 11.0.5+10-LTS) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11.0.5+10-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/sandreev/eclipses/eclipse4_16SDK_m20200505/hs_err_pid79084.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 79085 Dumping core ... See also: https://bugzilla.redhat.com/show_bug.cgi?id=1828845 In particular: https://bugzilla.redhat.com/show_bug.cgi?id=1828845#c46 > Severin noticed he could reproduce a memory stomping error simply running eclipse with a fastdebug JVM. > I ran it in a debugger and I see some eclipse native code corrupts > memory. That could lead to any weird crash. > > Most likely a build we would provide would make no difference. fastdebug or slowdebug build doesn't matter, the attached crash log is from the slowdebug variant. Not being able to start with a debug JDK build means we can't debug JDK crashes all that well. E.g. https://bugzilla.redhat.com/show_bug.cgi?id=1828845 (linked above), where using parallel GC crashes our Eclipse+xtext based product.
I can reproduce this with: Eclipse SDK Version: 2020-06 (4.16) Build id: I20200505-1800 We also see it with 4.15.
I can start this one without a crash: Eclipse SDK Version: 2019-06 (4.12) Build id: I20190605-1800 It doesn't have the fix for bug 549733. Unfortunately reverting the code causes merge conflicts. But if I add this change, I also don't see the start-up crash: diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java index b77327e9f2..135579b6a3 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java @@ -1105,6 +1105,9 @@ void checkIMModule () { * @return true if the current theme is dark */ boolean checkAndSetThemeDetails (String themeName) { + if (true) { + return false; + } if (themeName.endsWith("-dark") || themeName.endsWith(":dark")) { System.setProperty("org.eclipse.swt.internal.gtk.theme", themeName); return true; Note that I'm debugging Eclipse with the above change, I hope this doesn't make a big difference. Without the above change, debugging Eclipse with the debug JDK does lead to a crash.
Looks like JNI crashes while releasing jboolean array (jni_ReleaseBooleanArrayElements)? V [libjvm.so+0x1420559] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x6f V [libjvm.so+0x91b3d1] report_fatal(char const*, int, char const*, ...)+0x157 V [libjvm.so+0x10b76cb] verify_memory(void*)+0x112 V [libjvm.so+0x10b7d05] os::free(void*)+0x99 V [libjvm.so+0x55b106] FreeHeap(void*)+0x18 V [libjvm.so+0xcd1463] jni_ReleaseBooleanArrayElements+0x2d5 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.gtk.OS.g_object_get(J[B[ZJ)V+0 j org.eclipse.swt.widgets.Display.checkAndSetThemeDetails(Ljava/lang/String;)Z+46 j org.eclipse.swt.widgets.Display.createDisplay(Lorg/eclipse/swt/graphics/DeviceData;)V+58 The code in checkAndSetThemeDetails(): long settings = GTK.gtk_settings_get_default (); boolean [] darkThemePreferred = new boolean [1]; OS.g_object_get(settings, GTK.gtk_application_prefer_dark_theme, darkThemePreferred, 0); The corresponding code is in oc.c, line 14858 and below. #ifndef NO_g_1object_1get__J_3B_3ZJ JNIEXPORT void JNICALL OS_NATIVE(g_1object_1get__J_3B_3ZJ) (JNIEnv *env, jclass that, jlong arg0, jbyteArray arg1, jbooleanArray arg2, jlong arg3) { jbyte *lparg1=NULL; jboolean *lparg2=NULL; OS_NATIVE_ENTER(env, that, g_1object_1get__J_3B_3ZJ_FUNC); if (arg1) if ((lparg1 = (*env)->GetByteArrayElements(env, arg1, NULL)) == NULL) goto fail; if (arg2) if ((lparg2 = (*env)->GetBooleanArrayElements(env, arg2, NULL)) == NULL) goto fail; g_object_get((GObject *)arg0, (const gchar *)lparg1, lparg2, (const gchar *)NULL); fail: if (arg2 && lparg2) (*env)->ReleaseBooleanArrayElements(env, arg2, lparg2, 0); if (arg1 && lparg1) (*env)->ReleaseByteArrayElements(env, arg1, lparg1, JNI_ABORT); OS_NATIVE_EXIT(env, that, g_1object_1get__J_3B_3ZJ_FUNC); } #endif I don't see any other references to "boolean[]" argument type in OS.java. The oracle doc says jboolean is unsigned 8 bits. No idea if GTK doesn't support "jboolean" (unsigned 8 bits) and uses/expects something different (int for signed 32 bits?). The GTK 3 reference is https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-get JNI types: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html @Nikita, I saw you did some work on GTK JNI code in the past: could you please check this code above?
Andrey, you're right. g_object_get expects a pointer to gboolean (4 bytes), SWT code gives it a 1-element Java boolean array (1 byte), so g_object_get writes past the end of the array. I'm not sure that this is the cause of the crash, but it's worth fixing anyway. Where can I download a debug build of JDK to test it?
New Gerrit change created: https://git.eclipse.org/r/162693
(In reply to Nikita Nemkin from comment #4) > Where can I download a debug build of JDK to test it? Thanks for the fast reply & patch! Simeon has one, I've pinged him, he isn't so fast :-)
The build is quite large to attach, all RPMs are 1G archived. I can test your fix though?
(In reply to Simeon Andreev from comment #7) > The build is quite large to attach, all RPMs are 1G archived. I can test > your fix though? Sure, please test it youself. I'll merge if the fix works for you.
(In reply to Nikita Nemkin from comment #4) > Where can I download a debug build of JDK to test it? You can try this link: https://drive.google.com/file/d/1sGN_cF5WFjbqAiNWHaMv-nNH7UjzLxlr/view?usp=sharing
Gerrit change https://git.eclipse.org/r/162693 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f8542f2ac4f69d858eef9cb20b9095e010eafe70
@Andrey, can you please verify for M3?
Yep, we don't see craches anymore with master.
