JabRef freeze in opening entry editor #2963

mlep · 2017-07-04T09:58:45Z

JabRef-4.0.0-dev--snapshot--2017-07-03--master--6897b10fb.jar on LInux Mint LMDE.

java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Steps to reproduce:

create a new database
Menu BibTeX -> New entry...
Select an entry type (such as article)

JabRef does not do anything (processor idle) and cannot even be closed.

Log File

$ java -jar ./bin/JabRef-4.0.0-dev--snapshot--2017-07-03--mast--6897b10fb.jar AI: INFO 04-07-2017 11:56, 19: Configuration file has been successfully found as resource File: grouptree.fxml not found, attempting with camel case Jul 04, 2017 11:56:48 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 File: grouptree.css not found, attempting with camel case Jul 04, 2017 11:57:44 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66 Jul 04, 2017 11:57:45 AM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.66

Siedlerchr · 2017-07-04T10:13:33Z

Could you please try again with an updated JRE? The log indicates that your runtime version is older than the version with which the javafx stuff was created
The current version is:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

ilippert · 2017-07-04T10:58:49Z

JabRef 4.0.0-dev--snapshot--2017-07-03--master--6897b10fb
Linux 4.11.8-200.fc25.x86_64 amd64
Java 1.8.0_131

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

I confirm the issue. Opening a database works. But double clicking an entry to open entry editor does not work and jabref freezes.

Siedlerchr · 2017-07-04T18:27:53Z

Hm, I just tested the steps above. On Xubuntu 16.04 (8GB ram) with oracle jdk I cannot reproduce this behaviour. It takes a moment to open the entry editor, but I can not report a freeze.

ilippert · 2017-07-04T19:16:50Z

@Siedlerchr I believe I use oracle jdk, because openjdk would/should be indicated when prompting the shell for java -version.

mlep · 2017-07-07T08:21:34Z

After update of Java from Oracle:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

and using the last master (JabRef-4.0.0-dev--snapshot--2017-07-06--master--edd3f7cc1.jar),
I get the same behavior: a freeze (if it takes a "moment", this is a very long moment... (> 10 minutes))
JabRef is not responding (even for closing the window). I had to kill it.
Note: no CPU usage reported.

In the terminal, I get:
$ java -jar JabRef-4.0.0-dev--snapshot--2017-07-06--master--edd3f7cc1.jar
AI: INFO 07-07-2017 10:15, 19: Configuration file has been successfully found as resource
File: grouptree.fxml not found, attempting with camel case
File: grouptree.css not found, attempting with camel case

So, no more warnings regarding JavaFX.

And same behavior when using an existing database and double-clicking on an entry (in an attempt to edit this entry).

lenhard · 2017-07-11T11:33:19Z

I just tried this with the current master on Windows 7. Everything is working fine. Could this be a linux problem?

mlep · 2017-07-11T11:45:32Z

Could be. Any way to help in the diagnosis?
BTW, if this bug is postpone to v4.1, it means JabRef 4.0 will be not usable for Linux users...

lenhard · 2017-07-11T11:56:16Z

We have Linux users (@Siedlerchr, @lynyus) that do not experience this problem, so it's not a blocker for Linux per se.

mlep · 2017-07-11T12:06:03Z

Sorry, I overlooked this point.
What kind of test can be carried out to investigate the cause?

LinusDietz · 2017-07-11T12:12:20Z

We just talked about that in the devcall and are also unsure what the underlying problem is and which information can help us to solve this issue for everybody. :/

lenhard · 2017-07-24T12:30:03Z

To follow up on this: What we need is someone who experiences this error (no one in the dev team can reproduce it, no one uses Mint) to install the development environment and debug the failure.

So far there were two people using Linux Mint experiencing this, but no other OS (if I didn't overlook something). It might be something in the Mint environment.

mlep · 2017-07-24T14:23:02Z

Note: JabRef-4.0-dev--snapshot--2017-07-22--master--8730d02d9.jar does not freeze when using

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

with

 openjfx-8u60

ilippert · 2017-07-24T19:03:48Z

I had confirmed the issue, too, and I am running Fedora.

matthiasgeiger · 2017-07-25T07:51:09Z

Can you please check which openjfx version you are using?
Thanks!

mlep · 2017-07-25T08:12:44Z

version 8.0.60

lenhard · 2017-07-27T19:32:46Z

@ilippert Good to know, thanks! Could you try out openjfx 8.0.60 and see if this solves the problem on your machine?

In #3038 we also have a Mint user who doesn't report that the entry editor crashes. So this is most definitely a javafx configuration problem on Linux that's not specific for a certain distro.

Can we just tell people to use the javafx version 8.0.60 if they experience this? I still see very little that we can do from the side of JabRef here.

ilippert · 2017-07-27T19:53:34Z

@lenhard Hmm, to be detailed:
I have now updated Java via http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html hopeing it includes openjfx 8.0.60. But, sorry, I am too much a lay person to know how I investigate, which version of openjfx I now have.

JabRef 4.0-dev--snapshot--2017-07-25--master--0847f5d15
Linux 4.11.11-300.fc26.x86_64 amd64
Java 1.8.0_144

uname -a results in
Linux 4.11.11-300.fc26.x86_64 #1 SMP Mon Jul 17 16:32:11 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

With this configuration the error persists.

matthiasgeiger · 2017-07-31T07:50:41Z

@Siedlerchr fixed an issue yesterday that let JabRef freeze in another context - see #3058.

If you are using a configuration with automatic timestamp updates upon changing an entry the underlying problem might also be the cause of the freezes reported by you @mlep and @ilippert

Could you please check, whether the problem persists with the latest master builds from https://builds.jabref.org/master ?

Thanks!

mlep · 2017-07-31T08:01:30Z

Works as expected with JabRef-4.0-dev--snapshot--2017-07-30--master--81e6e8ed6.jar
Great! Thanks!

ilippert · 2017-07-31T10:15:09Z

JabRef 4.0-dev--snapshot--2017-07-30--master--81e6e8ed6
Linux 4.11.11-300.fc26.x86_64 amd64
Java 1.8.0_144

does not work as expected; still crashes.

matthiasgeiger · 2017-07-31T11:25:00Z

... too bad.

Siedlerchr · 2017-07-31T15:21:48Z

@ilippert Could you please try to start JabRef from commandline and check if there is any exception or error printed?
e.g. java -jar JabRef.jar

ilippert · 2017-07-31T15:32:19Z

I did check, nothing gets printed in the shell after producing the freeze effect. I am happy to offer other traces - if you suggest which

matthiasgeiger · 2017-08-01T06:46:34Z

Okay, as the Problem is solved for @mlep now this might be related to some weird combination of different aspects.

Let's try to narrow the potential cause: Could you please export your preferences (Options -> Preferences -> Export in the lower left side of the Dialog) and then reset the preferences (same Dialog). Does the problem of freezing persist?

ilippert · 2017-08-01T08:51:17Z

thanks, the problem persists. This morning, I have even experienced a few java core dumps today. see https://pastebin.com/XkNReGKi
The vague pattern I experience about the core dumps is as follows: if I just download the latest master and run it, JabRef starts and crashes after some time, sometimes even before the UI shows up; then when I try to start JabRef again via the shell, I get the feedback
Error: Invalid or corrupt jarfile JabRef--master--latest.jar

Now, if I set the JabRef master jar as read only, the core dumps do not seem to happen.

Then I tested JabRef for the original issue, with no files opened, and preferences reset. I then created a new file, imported some entries; and once I attempt to open the entry editor, it crashes; and nothing is reported on the shell.

Siedlerchr · 2017-08-01T09:20:28Z

Regarding your java core dumps, I found this bug report with a potential solution:
https://bugs.openjdk.java.net/browse/JDK-8160933

As you say this only happens when you open the entry editor, I have the vague feeling that it could be related to the CSL citation style lib. but no idea how to fix this,

Could you try to compile and run it directly from source code?
E.g. do a git clone https://github.com/JabRef/jabref.git
Then cd into that directory JabRef and execute ./gradlew run
It will download all kind of libs, compile and then start.

ilippert · 2017-08-01T11:55:30Z

compiled and then started successfully. I am not registering anything in the shell when it crashes (crash reproduced).

ilippert · 2017-08-01T11:57:14Z

I have also now started without all my preferences. I have closed all files; and created a blank one. As soon as I create a new entry (that would be opened in the entry editor), JabRef breaks down.

I am happy to investigate further with your patient guidance

koppor · 2017-08-09T16:29:02Z

@ilippert We assume recent fedora with recent updates and OrcleJDK 1.8.131?

ilippert · 2017-08-09T16:40:09Z

thanks!
JabRef 4.0-dev--snapshot--2017-08-08--master--3acd1f8d0
Linux 4.11.11-300.fc26.x86_64 amd64
Java 1.8.0_144

this java version is from http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Fedora is up to date.

hmm, how does OrcleJDK 1.8.131 relate to Java 1.8.0_144?

koppor · 2017-08-09T16:56:35Z

git bisect lead us to c9566c2 - #2875

@ilippert Do you have a checkout? Can you confirm, that ./gradlew run at commit c9566c2 ( git checkout c9566c2) leads to a non-working JabRef, but ea76246 works?

ilippert · 2017-08-09T17:44:38Z

hi,
56577b5 leads to crash when attempting to open the entry editor.

c9566c2 allows me partially to use the editor; though it literally takes seconds for the entry editor to load. I can then work in the editor and close it with the entry editor close button (I can repeat this for many entries >10). However, when I simply click onto another entry in the entry table whilst having opened the entry editor (hoping to open the entry editor for that other entry), it normally crashes (with one exception in which it did not directly crash).

ea76246 allows me partially to use the editor: opening the editor is much much faster (within a one second range; sometimes, however, JabRef directly crashes when trying to open the entry editor). I can then work in the editor and close it with the entry editor close button. Sometimes, it works then to open the entry editor for another entry (sometimes it crashes then; I achieved opening max 2 or 3 different entries in the entry editor). However, when I simply click onto another entry in the entry table whilst having opened the entry editor (hoping to open the entry editor for that other entry), it directly crashes.

Sorry, this is not a straightforward confirmation...

ilippert · 2017-08-09T18:29:41Z

"playing" with various checkouts...

beta works wonderfully, of course ;) that is: 0bbb930

c3a898f, 3acd1f8, 3344c629c114349115354fbaa7b08da593b055 and 6c4e71c do not allow me to open entry editor.

ede4dc8, fcac527, a9e2066 work wonderfully.

b02433b gets me to a behaviour in which I can open the entry editor, but then it starts to crash, similar to the description in #2963 (comment)

4832e5d, 4543592 do not seem to have an entry editor ;)

7818515 does have the frame of the editor, but not fields; but no crashes ;)

koppor · 2017-08-10T10:08:44Z

Oh, wow, good to know.

Superficial question: Does snap install jabref --edge --devmode work at your side and does the snap JabRef work (Refs #2345)?

ilippert · 2017-08-11T00:10:53Z

works well, it snap run jabref seems to run faster than the other ways of running jabref.

I get a range of warnings, like
WARNING: Loading FXML document with JavaFX API of version 8.0.112 by JavaFX runtime of version 8.0.111 Aug 11, 2017 2:07:25 AM javafx.fxml.FXMLLoader$ValueElement processValue

as well as

(java:3766): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", (java:3766): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita", Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module"

Siedlerchr · 2017-08-14T09:48:37Z

So apart from some GTK errors and the warnings, the snap works fine and does not crash?

ilippert · 2017-08-14T09:54:57Z

yes, indeed - it works fine at least with respect to this current issue of the entry editor; I did not check it with respect to other issues.

Siedlerchr · 2017-08-14T09:57:28Z

Okay, so I would close this for the moment.

tobiasdiez added bug Confirmed bugs or reports that are very likely to be bugs entry-editor status: waiting-for-feedback The submitter or other users need to provide more information about the issue labels Jul 4, 2017

tobiasdiez added this to the v4.0 milestone Jul 4, 2017

lenhard added the os: linux label Jul 11, 2017

lenhard modified the milestones: v4.1, v4.0 Jul 11, 2017

koppor removed the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Jul 18, 2017

lenhard marked this as a duplicate of #3043 Jul 23, 2017

lenhard mentioned this issue Jul 23, 2017

Jabref 4.0 beta 2 freeze after creating a new entry #3043

Closed

Siedlerchr closed this as completed Jul 31, 2017

matthiasgeiger reopened this Jul 31, 2017

koppor added status: devcall and removed status: devcall labels Aug 10, 2017

Siedlerchr added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Aug 14, 2017

Siedlerchr closed this as completed Aug 14, 2017

lenhard mentioned this issue Sep 26, 2017

Freezes under Linux #3234

Closed

lenhard mentioned this issue Oct 5, 2017

Jabref hangs after pasting bibtex code into source field #3261

Closed

JabRef freeze in opening entry editor #2963

JabRef freeze in opening entry editor #2963

Comments

mlep commented Jul 4, 2017

Siedlerchr commented Jul 4, 2017

ilippert commented Jul 4, 2017

Siedlerchr commented Jul 4, 2017 • edited by koppor Loading

ilippert commented Jul 4, 2017

mlep commented Jul 7, 2017

lenhard commented Jul 11, 2017

mlep commented Jul 11, 2017

lenhard commented Jul 11, 2017 • edited by LinusDietz Loading

mlep commented Jul 11, 2017

LinusDietz commented Jul 11, 2017

lenhard commented Jul 24, 2017

mlep commented Jul 24, 2017

ilippert commented Jul 24, 2017

matthiasgeiger commented Jul 25, 2017

mlep commented Jul 25, 2017

lenhard commented Jul 27, 2017

ilippert commented Jul 27, 2017

matthiasgeiger commented Jul 31, 2017 • edited Loading

mlep commented Jul 31, 2017

ilippert commented Jul 31, 2017

matthiasgeiger commented Jul 31, 2017

Siedlerchr commented Jul 31, 2017

ilippert commented Jul 31, 2017

matthiasgeiger commented Aug 1, 2017

ilippert commented Aug 1, 2017

Siedlerchr commented Aug 1, 2017

ilippert commented Aug 1, 2017

ilippert commented Aug 1, 2017

koppor commented Aug 9, 2017

ilippert commented Aug 9, 2017

koppor commented Aug 9, 2017 • edited Loading

ilippert commented Aug 9, 2017

ilippert commented Aug 9, 2017

koppor commented Aug 10, 2017

ilippert commented Aug 11, 2017 • edited Loading

Siedlerchr commented Aug 14, 2017

ilippert commented Aug 14, 2017

Siedlerchr commented Aug 14, 2017

Siedlerchr commented Jul 4, 2017 •

edited by koppor

Loading

lenhard commented Jul 11, 2017 •

edited by LinusDietz

Loading

matthiasgeiger commented Jul 31, 2017 •

edited

Loading

koppor commented Aug 9, 2017 •

edited

Loading

ilippert commented Aug 11, 2017 •

edited

Loading