search

kaikramer / keystore-explorer

KeyStore Explorer is a free GUI replacement for the Java command-line utilities keytool and jarsigner.
https://keystore-explorer.org/
GNU General Public License v3.0
1.67k stars 271 forks source link

Version 5.5.* simply freezes after showing the gui #368

Closed SanskritFritz closed 1 year ago

SanskritFritz commented 2 years ago

I tired to build from source with maven or use the zip file, keystore-explorer simply freezes after showing the gui. Nothing is shown in the console when started there.

The last lines of strace:

rt_sigaction(SIGRT_1, {sa_handler=0x7fe25a517940, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fe25a4cf560}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fe258ce2000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
clone(child_stack=0x7fe258de0ef0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[22918], tls=0x7fe258de1640, child_tidptr=0x7fe258de1910) = 22918
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x7fe258de1910, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 22918, NULL, FUTEX_BITSET_MATCH_ANY

I can provide all strace logs if required. What other information do you need?

kaikramer commented 2 years ago

Thanks for the bug report. However, this is probably not something that can be fixed in KSE. It sounds more like a problem between GUI libraries (like GTK) and the Java runtime.

Some questions:

SanskritFritz commented 2 years ago 
* Does the problem also occur with OpenJDK 11?

With OpenJDK 11 it works. Thanks for the tip!

  • Do you have the package "java-openjfx" (or similar name with "jfx" in it) installed? No, only OpenJDK 11 and 17 are installed.
  • Do you have GTK2 or GTK3 packages installed? Both GTK2 and GTK3 are installed.

OK, now that I answered your questions, I realised by accident that there was probably something wrong with my java configuration. Because, for the testing with java 11 I issued the following command: archlinux-java set java-11-openjdk (This is how more java versions can coexist in Archlinux.) Then after the test I switched back: archlinux-java set java-17-openjdk and to my surprise Keystore Explorer 5.5.1 still works perfectly. Hence I think there was a problem in my Archlinux install and those commands did fix the configuration. Thank you for caring and sorry for the noise. Closing...

SanskritFritz commented 2 years ago

I'm not going to reopen this because I believe you that this is not a problem with KSE, but I'm humbly asking for some more help. The same problem returned after switching to java18 but this time the aforementioned hack doesn't help. So I had to revert to KSE version 5.4 to still be able to use it. Can you please give me a hand again in pinpointing the problem? Thanks in advance.

kaikramer commented 2 years ago

Sure, I help where I can. I have five Linux VMs just for testing KSE in various environments, unfortunately no Arch-based distribution among them. I probably should change that, because right now I have no idea what to look for.

SanskritFritz commented 2 years ago

Thanks for caring. Would a strace help?

kaikramer commented 2 years ago

For me it would be ideal if I could reproduce the problem on my machine. Then I can also search for the cause and possible solutions much faster and easier. I have found an old Manjaro VM that I have updated to match your configuration (KDE Plasma, Java versions). So far I couldn't reproduce the problem, KSE works fine with both Java 11 and 17. The only "special" thing I did was to set the environment variable _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on' to fix the font rendering.

How do you start KSE? From the command line or via click on kse.sh or kse.jar?

BTW, there are KSE packages in AUR, see https://repology.org/project/keystore-explorer/versions.

SanskritFritz commented 2 years ago

I tried to start KSE from the desktop, or from the shell, same result. If I start it by opening a jks file, the password prompt is active, I can enter the password, then the contents of the file appear normally in KSE and then the program freezes. One more thing: I have two archlinux installations, one at my workplace and one at home. They're on the same upgrade level, very similar desktops but there is one big difference: the workplace environment is running a headless server on a WMware virtual machine where the Plasma desktop is started via .vnc/config, so no phisycal display is connected so I can use it only via vncviewer. And here is where KSE 5.5 freezes, as opposed to my home box where it is working fine. I tried both keystore-explorer-bin, keystore-explorer-git from the AUR.

kaikramer commented 2 years ago

That's an important information, why didn't you tell me earlier? Not sure what VNC changes, but I'll try it in my setup...

SanskritFritz commented 2 years ago

That's an important information, why didn't you tell me earlier?

Because earlier KSE acted the same on both systems.

Not sure what VNC changes,

Probably most importantly polkit lists my user as "inactive user". Previously I had problems with that so I had to adjust some settings.

kaikramer commented 2 years ago

Alright, so in the meantime I have installed TigerVNC in the VM, started it with "x0vncserver ..." and still cannot reproduce the problem. KSE runs just fine in the VNC session. The reason for that might be that VNC is not related to the freezing or that your VNC setup is different. I saw in the link that you are starting the VNC server at system start via systemd. I'll try that next weekend.

Are you using any other software that is written in Java? If not you could check if for example this demo application or this password manager freeze as well.

SanskritFritz commented 2 years ago

x0vncserver starts a physical session, that is different. Try the virtual desktop according to the wiki and use it through vncviewer.

Both Jpass and Flatlaf demo work well here, just like KSE 5.4

kaikramer commented 2 years ago

Some updates:

The way the splash image is shown (technically) has changed a bit in version 5.5.0, but as I understand the application freezes after it has already completely started, so this should not be relevant here either.

Thinking about what KSE does right after the start does not lead to anything interesting :

It is a pity that I cannot reproduce the issue. Otherwise I could simply compile KSE from different git commits between the v5.4.4 and v5.5.0 tag, test if the problem occurs with this version and by doing this locating the commit that caused this.

SanskritFritz commented 2 years ago

I'm willing to test every commit one by one. I simply should use ./gradlew clean build on a relevant checkout, right?

Also if you're willing, you could provide a debug version that writes lots of information to the stdout. Maybe we can see where it crashes more precisely then.

kaikramer commented 2 years ago

I'm willing to test every commit one by one. I simply should use ./gradlew clean build on a relevant checkout, right?

Yes, and Git provides a very helpful command here: https://git-scm.com/docs/git-bisect

SanskritFritz commented 2 years ago

Indeed git bisect is wonderful, thanks for the tip! This was the first time I used it so it was a wonderful learning experience. Now this is the result:

frank@frank-desktop ~/b/F/k/keystore-explorer ((6562d075…)|BISECTING)> git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a3edb2b0b2ab105f96710ceb9daa4e2a77896e4d] Fixed scaling issue with splash image (ticket #133)
frank@frank-desktop ~/b/F/k/k/kse ((a3edb2b0…)|BISECTING)> ./gradlew clean build

> Task :compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

BUILD SUCCESSFUL in 25s
9 actionable tasks: 9 executed
frank@frank-desktop ~/b/F/k/keystore-explorer ((a3edb2b0…)|BISECTING)> git bisect bad
a3edb2b0b2ab105f96710ceb9daa4e2a77896e4d is the first bad commit
commit a3edb2b0b2ab105f96710ceb9daa4e2a77896e4d
Author: Kai Kramer <kaikramer@users.noreply.github.com>
Date:   Sun Oct 10 01:07:37 2021 +0200

    Fixed scaling issue with splash image (ticket #133)

    Splash image is now shown with "-splash:" start option and splash files
    lying in file system instead of "SplashScreen-Image:" in MANIFEST.MF and
    embedded images in jar. For some reason the splash screen is only scaled
    in the former case.

 kse-launcher/src/main.rs                           |   2 +
 kse/build.gradle                                   |  13 ++----
 kse/image-src/splash@2x.pdn                        | Bin 0 -> 159904 bytes
 kse/innosetup/setup.iss.template                   |   1 +
 kse/res/kse                                        |   2 +-
 kse/res/kse-launcher.exe                           | Bin 249358 -> 249358 bytes
 kse/res/kse.sh                                     |   5 +-
 kse/res/splash.png                                 | Bin 0 -> 40816 bytes
 kse/res/splash@2x.png                              | Bin 0 -> 113294 bytes
 kse/src/org/kse/KSE.java                           |  38 +--------------
 kse/src/org/kse/gui/CreateApplicationGui.java      |  51 ++++++---------------
 kse/src/org/kse/gui/actions/CheckUpdateAction.java |  46 +++++++++++++------
 kse/src/org/kse/gui/dialogs/DCheckUpdate.java      |   3 +-
 kse/src/org/kse/gui/images/splash.png              | Bin 40816 -> 0 bytes
 kse/src/org/kse/resources.properties               |   8 ----
 kse/src/org/kse/resources_de.properties            |  24 ----------
 kse/src/org/kse/resources_fr.properties            |   7 ---
 17 files changed, 60 insertions(+), 140 deletions(-)
 create mode 100644 kse/image-src/splash@2x.pdn
 create mode 100644 kse/res/splash.png
 create mode 100644 kse/res/splash@2x.png
 delete mode 100644 kse/src/org/kse/gui/images/splash.png
 delete mode 100644 kse/src/org/kse/resources.properties
 delete mode 100644 kse/src/org/kse/resources_de.properties
 delete mode 100644 kse/src/org/kse/resources_fr.properties
kaikramer commented 2 years ago

Very nice, thank you! There are two possibilities now what the cause of this problem might be (and also two possible workarounds for you):

  1. The splash image. I don't think this is the cause, but in case the second workaround should not work, you can try this one. Just remove the splash parameter in the start script: -splash:${SCRIPT_DIR}/splash.png

  2. The automatic update check was refactored in this commit as well. This would match your description that the freeze happens shortly after the application has started. You can simply disable the update check in the preferences.

SanskritFritz commented 2 years ago

2. You can simply disable the update check in the preferences.

So I did and presto! I'm happily using 5.5.1 right now! Thank you for taking the time for your very valuable help. So, could it be that KSE tried to check for a new version but since we have an ntlm proxy here it just got stuck at the request? Maybe after a timeout it would have worked?

kaikramer commented 2 years ago

Yes, exactly, but I still don't quite understand it because the update check runs in a background thread and should never freeze the application.

Anyway, I know where to look now and there will be a fix in the next release.

SanskritFritz commented 2 years ago

Anyway, I know where to look now and there will be a fix in the next release.

If you need a tester, I'm available :smile:

kaikramer commented 2 years ago

If you need a tester, I'm available 😄

I'm counting on it 😄