Community
Participate
Working Groups
Created attachment 285915 [details] Error report made by Java OS: Kubuntu 20.10 Groovy Gorilla Newly unpacked Eclipse 2021-03, tried internal OpenJDK 15, the one provided by Ubuntu and even OpenJDK 11 When trying to open the following menu: Window - Preferences - General - Security - Secure Storage there is a segmentation fault. This is what I see in the console: (Eclipse:31798): GLib-GIO-CRITICAL **: 18:35:12.983: g_dbus_proxy_get_object_path: assertion 'G_IS_DBUS_PROXY (proxy)' failed # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f5c096d6764, pid=31798, tid=31799 # # JRE version: OpenJDK Runtime Environment (15.0.2+7) (build 15.0.2+7-27) # Java VM: OpenJDK 64-Bit Server VM (15.0.2+7-27, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libglib-2.0.so.0+0x41764] g_str_hash+0x4 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/antonio/javadev/ide/eclipse-202103/core.31798) # # An error report file with more information is saved as: # /home/antonio/javadev/ide/eclipse-202103/hs_err_pid31798.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # I attached the error report.
Can you please keep the core dump? Run following: gdb /home/antonio/javadev/ide/eclipse-202103/core.31798 and enter "bt" - that should show the backtrace. Please attach it here.
Moving to equinox: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.sun.jna.Native.invokeInt(Lcom/sun/jna/Function;JI[Ljava/lang/Object;)I+0 j com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;ZI)Ljava/lang/Object;+211 j com.sun.jna.Function.invoke(Ljava/lang/reflect/Method;[Ljava/lang/Class;Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+271 j com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+344 j org.eclipse.equinox.internal.security.linux.$Proxy24.secret_service_unlock_sync(Lcom/sun/jna/Pointer;Lorg/eclipse/equinox/internal/security/linux/GList;Lcom/sun/jna/Pointer;Lcom/sun/jna/ptr/PointerByReference;Lcom/sun/jna/ptr/PointerByReference;)I+34 j org.eclipse.equinox.internal.security.linux.LinuxPasswordProvider.unlockSecretService()V+378 j org.eclipse.equinox.internal.security.linux.LinuxPasswordProvider.canUnlock()Z+1 j org.eclipse.equinox.internal.security.linux.LinuxPasswordProvider.isValid()Z+1 j org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.findAvailableModules(Ljava/lang/String;)Ljava/util/List;+331 j org.eclipse.equinox.internal.security.storage.friends.InternalExchangeUtils.passwordProvidersFind()Ljava/util/List;+4 j org.eclipse.equinox.internal.security.ui.storage.TabPassword.fillProviderTable()V+48 j org.eclipse.equinox.internal.security.ui.storage.TabPassword.<init>(Lorg/eclipse/swt/widgets/TabFolder;ILorg/eclipse/swt/widgets/Shell;)V+439 j org.eclipse.equinox.internal.security.ui.storage.StoragePreferencePage.createContents(Lorg/eclipse/swt/widgets/Composite;)Lorg/eclipse/swt/widgets/Control;+46 j org.eclipse.jface.preference.PreferencePage.createControl(Lorg/eclipse/swt/widgets/Composite;)V+88 j org.eclipse.jface.preference.PreferenceDialog.createPageControl(Lorg/eclipse/jface/preference/IPreferencePage;Lorg/eclipse/swt/widgets/Composite;)V+2 j org.eclipse.jface.preference.Preference
*** Bug 572198 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/178240
Problem is due to faulty JNA coding of glist append call. I have provided a patch. The problem occurs if the default collection is currently locked.
(In reply to Andrey Loskutov from comment #1) > Can you please keep the core dump? > Run following: > > gdb /home/antonio/javadev/ide/eclipse-202103/core.31798 > > and enter "bt" - that should show the backtrace. Please attach it here. I am sorry the core dump has not been created, later I will replicate the problem and attach it.
*** Bug 572217 has been marked as a duplicate of this bug. ***
(In reply to Andrey Loskutov from comment #1) > Can you please keep the core dump? > Run following: > > gdb /home/antonio/javadev/ide/eclipse-202103/core.31798 > > and enter "bt" - that should show the backtrace. Please attach it here. I think that the backtrace without the debug symbols, however here it is: #0 0x00007fa5f2bd68cb in ?? () #1 0xfffffffe7ffbfa07 in ?? () #2 0x0000000000000010 in ?? () #3 0x00007fa5f2814b82 in ?? () #4 0x00007fa5f245e77e in ?? () #5 0x0000000000000008 in ?? () #6 0x00000000000007d0 in ?? () #7 0x00007fa5f159db50 in ?? () #8 0x00007fa5f2814b82 in ?? () #9 0x00007fa5f159d9b0 in ?? () #10 0x00007fa5f245f45b in ?? () #11 0x0000000000000001 in ?? () #12 0x00007fa5f2c9dda4 in ?? () #13 0x00007fa5f159d9c0 in ?? () #14 0x0000000000000005 in ?? () #15 0x00007fa5f2b44940 in ?? () #16 0x0000000000000005 in ?? () #17 0xfffffffe7fffffff in ?? () #18 0xffffffffffffffff in ?? () #19 0xffffffffffffffff in ?? () #20 0xffffffffffffffff in ?? () #21 0xffffffffffffffff in ?? () #22 0xffffffffffffffff in ?? () #23 0xffffffffffffffff in ?? () #24 0xffffffffffffffff in ?? () #25 0xffffffffffffffff in ?? () #26 0xffffffffffffffff in ?? () #27 0xffffffffffffffff in ?? () #28 0xffffffffffffffff in ?? () #29 0xffffffffffffffff in ?? () #30 0xffffffffffffffff in ?? () #31 0xffffffffffffffff in ?? () #32 0xffffffffffffffff in ?? () #33 0x00007fa5f159db10 in ?? () #34 0x6e11ee8aa655fc00 in ?? () #35 0x00007fa5f159daa0 in ?? () #36 0x00007fa5f2bbb864 in ?? () #37 0x0000000000000020 in ?? () #38 0x00000000000007d0 in ?? () #39 0x00007fa5f159db50 in ?? () #40 0x0000003000000010 in ?? () #41 0x00007fa5f159dab0 in ?? () #42 0x00007fa5f159d9c0 in ?? () #43 0x0000000000006c83 in ?? () #44 0x0000000000023bc0 in ?? () #45 0x000000000000000a in ?? () #46 0x00007fa5f27d205f in ?? () #47 0x0000000000000000 in ?? ()
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/178240 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=db617439cfa411f0e8cbd5ef26950dab8d5f58c4
Any mitigation? Because now Eclipse is completely unusable for me. Any git Operation or even opening the secure storage settings crashes Eclipse immediately.
I use this workaround on Ubuntu before starting eclipse: - Open the seahorse (application for managing encryption keys and passwords in the GNOME Keyring) - The "Default keyring" is locked. Right click and select unlock.
A fix has been made and is part of the latest 4.20-I-builds. Could you try downloading the Eclipse SDK from: https://download.eclipse.org/eclipse/downloads/drops4/I20210325-1800/ and testing to verify if the problem is fixed for your set-up.
The proposed workaround seems to work. Tried to test the drop but it lacks all features I would need to test our plugin.
Tested the https://download.eclipse.org/eclipse/downloads/drops4/I20210325-1800/. I installed egit and this version of eclipse does not crash when pulling from git. So it seems to be fixed.
It works! However I hope that this fix is backported to 4.19, since this version is useless without it.
(In reply to Antonio Petrelli from comment #15) > It works! However I hope that this fix is backported to 4.19, since this > version is useless without it. Hi Antonio, Have you tried the suggested workaround to manually unlock the default keyring?
(In reply to Jeff Johnston from comment #16) > (In reply to Antonio Petrelli from comment #15) > > It works! However I hope that this fix is backported to 4.19, since this > > version is useless without it. > > Hi Antonio, > > Have you tried the suggested workaround to manually unlock the default > keyring? Yes, it works, I just tried it. Notice that I tried the 4.20 integration build *before* unlocking the keyring (and it worked). Notice that I am in KDE and I had to install seahorse because is not bundled with it. Luckily it is not disruptive. Saving passwords works too with the workaround. Anyway I think that backporting this fix is better that saying people to unlock the keyring at every login.
Created attachment 285992 [details] Updated Eclipse Security for Linux Source for updated fragment with patch
(In reply to Antonio Petrelli from comment #17) > (In reply to Jeff Johnston from comment #16) > > (In reply to Antonio Petrelli from comment #15) > > > It works! However I hope that this fix is backported to 4.19, since this > > > version is useless without it. > > > > Hi Antonio, > > > > Have you tried the suggested workaround to manually unlock the default > > keyring? > > Yes, it works, I just tried it. Notice that I tried the 4.20 integration > build *before* unlocking the keyring (and it worked). > Notice that I am in KDE and I had to install seahorse because is not bundled > with it. Luckily it is not disruptive. > Saving passwords works too with the workaround. > Anyway I think that backporting this fix is better that saying people to > unlock the keyring at every login. Hi Antonio, Backporting is difficult to do and get permission for but I understand the annoyance of the manual work-around each time. To that end, I have posted the source for the org.eclipse.equinox.security.linux fragment project with patch as a zip which you can download. If you go to File -> Import -> General -> Existing Projects into Workspace and then click on Select Archive, you can specify the location of the zip file you downloaded and hit Finish. This will bring the fragment project into your workspace. If you then right-click on the org.eclipse.equinox.security.linux fragment project and select Export... -> Plug-in Development -> Deployable Plugins and Fragments then choose the last Destination option: "Install into host: Repository" and hit Finish, the fragment update will get installed into your Eclipse and you won't have to do anything manual after that. It will warn you about it not being signed, but that is expected since it is directly from the fragment project. You can verify by looking at Help -> About Eclipse IDE -> Installation Details -> Plugins and you should see that the org.eclipse.equinox.security.linux fragment is version 1.0.100.xxxxxx. This fix is unnecessary for systems which unlock the default keyring on login.
*** Bug 572545 has been marked as a duplicate of this bug. ***
(In reply to Jeff Johnston from comment #19) > Backporting is difficult to do and get permission for But what is Backporting/Update Sites are good for if even such a serve problem (eclipse crashes with all unsaved work is gone, probably workspace corruption) is not worth it?
Hi Jeff, thanks for the workaround. It works on my Linux Mint 20 following your instructions. It seems to require the Plugin-Development Environment installed in Eclipse to have the necessary export target available. A pure Java edition of Eclipse seems not to work.
*** Bug 572701 has been marked as a duplicate of this bug. ***
*** Bug 573763 has been marked as a duplicate of this bug. ***
