Closed stefan-kolb closed 4 years ago
@stefan-kolb Cannot reproduce:
The huge installer size before was due to duplicate modules : https://github.com/JabRef/jabref/pull/6711
I just tested with the latest master msi and zip: (JRE is included)
JabRef 5.1--2020-08-25--2ce90ad Windows 10 10.0 amd64 Java 15-ea
You have to wait 10 seconds until it starts. Maybe more.
Tested locally here.
I am very aware that we have a performance issue at the start. For the blog post at https://github.com/JabRef/blog.jabref.org/pull/47, I started all JabRe versions from 2.0 onwards. I think, from 4.0 onwards, the start was very slow. - 2.0, in contrast, was very fast.
The "maybe" release builds are available at https://builds.jabref.org/v5.1-maybe/
We need more testing in this.
Sorry that I cannot provide more details for this. It happened on Kaddas PC. Needed to go back to 5.0 asap (unfortunately it is really slow/freezing).
You might close this as long as I cannot provide a more detailed test.
I have one more user with the same issue.
Maybe because of https://github.com/JabRef/jabref/pull/6748
One user confirmed that starting from the bat files works : C:\Program Files\JabRef\runtime\bin\JabRef.bat
I had this issue some time ago with the portable version
One user confirmed that starting from the bat files works : C:\Program Files\JabRef\runtime\bin\JabRef.bat
Confirmed by a test user
Note: in the bin
directory of the windows portable version, there is no JabRef.bat
.
But there are a JabRefHost.bat
and a JabRef.exe
.
Which one is to be used?
Answer by @Siedlerchr (https://github.com/JabRef/jabref/issues/6801#issuecomment-681996801_)
bat file is located in JabRef-5.1-portable_windows\JabRef\runtime\bin
Not obvious, and that not match the doc. I am going to alter the doc.
@stefan-kolb Can you start JabRef.exe
from the command line?
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=9800, tid=6068
#
# JRE version: (15.0+36) (build )
# Java VM: OpenJDK 64-Bit Server VM (15-ea+36, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C 0x0000000000000000
--------------- S U M M A R Y ------------
Command Line: -Djdk.module.main=org.jabref org.jabref/org.jabref.JabRefLauncher
Host: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 4 cores, 7G, Windows 10 , 64 bit Build 17763 (10.0.17763.1339)
Time: Thu Aug 27 17:20:28 2020 Mitteleuropäische Sommerzeit elapsed time: 0.178221 seconds (0d 0h 0m 0s)
--------------- T H R E A D ---------------
Current thread (0x0000019ef0be26f0): JavaThread "Unknown thread" [_thread_in_vm, id=6068, stack(0x0000005f62600000,0x0000005f62700000)]
Stack: [0x0000005f62600000,0x0000005f62700000], sp=0x0000005f626ff138, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), data execution prevention violation at address 0x0000000000000000
Note that using the .bat
file in a sub directory is only a work around. JabRef.exe
should work, too. Otherwise, it is not obvious for the user.
data execution prevention violation at address : Windows Data Execution Prevention is a problem. Could be a problem of the zulu jdk.
Unfortunately adoptopenjkd did not work for windwos when compiling: error: module not found: jdk.internal.vm.compiler requires jdk.internal.vm.compiler;
Task :compileJava FAILED
See the log for an example https://github.com/JabRef/jabref/pull/6748/checks?check_run_id=1009424853
Can we use Java 14 for Windows and Java 15 EA for Mac? 😇
You just need to adapt the line here: https://github.com/JabRef/jabref/blob/f81f61984e222b7b7883b42b0278a616d2adbc19/.github/workflows/deployment.yml#L61-L65
Please try this one @stefan-kolb https://builds.jabref.org/pull/6802/merge/
Would it be possible to get a list of instructions on how to reproduce the crash with the JDK 15 EA builds? Need to establish if this is a JDK bug so that it is tracked in the JDK Bug System.
@AlanBateman We think it's a problem specifically of the zulu (Azul jdk) variant probably because it's not digitally signed or so. I noticed that the MacOS variant wasn't signed at all and guess the windows version isn't either.
I am trying now a build again with AdoptOpenJKD and report back. https://github.com/JabRef/jabref/pull/6829
@AlanBateman The AdoptOpenJDK Version reports a missing module on windows https://github.com/JabRef/jabref/pull/6829/checks?check_run_id=1055196773
:\a**\src\main\java\module-info.java:67: error: module not found: jdk.internal.vm.compiler requires jdk.internal.vm.compiler;
The snippet with the crash/error log says windows-amd64. If there is a crash with the JDK 15 EA builds (from http://jdk.java.net/15/) then it would be useful to get more information.
We did not find out the configuration of the machines leading to a crash yet. The crash reported at https://github.com/koppor/jabref/issues/465#issuecomment-682019079 appears by other persons. Once company-maintained, one "normal" Winows installation. Runs on my machine though.
@AlanBateman Do you have a minimal java application build with jpackage? Then, I could let that test on different platforms. I could maybe build some for myself somewhere later this week.