Jabre-4.x does not exit cleanly #2955

jonasstein · 2017-07-02T15:58:27Z

The GUI disappears after running File/Quit from the menu, but Jabref does not return to console.
Need to press Ctrl+C several times.

Started from commandline with java -jar jabref.jar

JabRef 4.0.0-dev--snapshot--2017-06-29--master--7e50e84a1
Linux 4.9.16-gentoo+ amd64 
Java 1.8.0_131

The text was updated successfully, but these errors were encountered:

Siedlerchr · 2017-07-02T21:58:14Z

On windows (started with ./gradlew run from sourcecode) I can not reproduce this. It might be the case that there is still some background thread which does write a backup or whatever and takes some time.
Does JabRef finish after a while when you don't stop the process? E.g. wait some minutes and check again.

Siedlerchr · 2017-07-04T18:29:48Z

I also tested it directly from command line on Xubuntu 16.04 with the steps you provided and it exits cleanly. Do you have any save actions defined which might delay the exiting?

jonasstein · 2017-07-04T19:34:32Z

I have already updated to a more recent version and I retried several times. I have to agree, that it is not so easy to reproduce anymore. I will have to investigate a bit more what causes it. Sometimes it exits in 3 seconds (which is quite slow for an simple GUI on a i7 cpu), some times it takes longer. I think the best is we close the ticket and I open a new ticket, when I can provide useful details.

michaellass · 2017-10-05T21:02:13Z

I also have this issue and can reproduce it every single time. It seems to only occur when a database is open, although I am not 100% about this aspect.

I ran JabRef in an Eclipse debug session and got the following stack trace when the application is hanging on exit:

org.jabref.JabRefMain at localhost:42377 (Suspended)	
	Daemon System Thread [Signal Dispatcher] (Suspended)	
	Daemon System Thread [Finalizer] (Suspended)	
		waiting for: ReferenceQueue$Lock  (id=73)	
	Daemon System Thread [Reference Handler] (Suspended)	
		waiting for: Reference$Lock  (id=74)	
	Daemon Thread [Thread-1] (Suspended)	
		Unsafe.park(boolean, long) line: not available [native method]	
		LockSupport.park(Object) line: 175	
		AbstractQueuedSynchronizer$ConditionObject.await() line: 2039 [local variables unavailable]	
		LinkedBlockingDeque<E>.takeFirst() line: 492 [local variables unavailable]	
		InvokeLaterDispatcher.run() line: 108	
	Daemon System Thread [Java2D Disposer] (Suspended)	
		waiting for: ReferenceQueue$Lock  (id=75)	
	Daemon System Thread [AWT-XAWT] (Suspended)	
		XToolkit.waitForEvents(long) line: not available [native method]	
	Daemon Thread [Timer-0] (Suspended)	
		waiting for: TaskQueue  (id=70)	
		Object.wait(long) line: not available [native method]	
		TimerThread.mainLoop() line: 552	
		TimerThread.run() line: 505	
	Daemon Thread [timer] (Suspended)	
		waiting for: TaskQueue  (id=71)	
		Object.wait(long) line: not available [native method]	
		TaskQueue(Object).wait() line: 502	
		TimerThread.mainLoop() line: 526	
		TimerThread.run() line: 505	
	Daemon System Thread [Prism Font Disposer] (Suspended)	
		waiting for: ReferenceQueue$Lock  (id=72)	
		Object.wait(long) line: not available [native method]	
		ReferenceQueue<T>.remove(long) line: 143	
		ReferenceQueue<T>.remove() line: 164 [local variables unavailable]	
		Disposer.run() line: 93	
		Thread.run() line: 748 [local variables unavailable]	
	Thread [pool-4-thread-1] (Suspended)	
		Unsafe.park(boolean, long) line: not available [native method]	
		LockSupport.park(Object) line: 175	
		FutureTask<V>.awaitDone(boolean, long) line: 429	
		FutureTask<V>.get() line: 191	
		DefaultTaskExecutor.runInJavaFXThread(Callable<V>) line: 32	
		JabRefFrame.lambda$2() line: 665	
		310023215.call() line: not available	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).run() line: 266	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$201(ScheduledThreadPoolExecutor$ScheduledFutureTask) line: 180	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run() line: 293	
		ScheduledThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1149	
		ThreadPoolExecutor$Worker.run() line: 624 [local variables unavailable]	
		Thread.run() line: 748 [local variables unavailable]	
	Daemon Thread [SwingWorker-pool-6-thread-1] (Suspended)	
		Unsafe.park(boolean, long) line: not available [native method]	
		LockSupport.park(Object) line: 175	
		AbstractQueuedSynchronizer$ConditionObject.await() line: 2039 [local variables unavailable]	
		LinkedBlockingQueue<E>.take() line: 442 [local variables unavailable]	
		ThreadPoolExecutor.getTask() line: 1074	
		ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1134	
		ThreadPoolExecutor$Worker.run() line: 624 [local variables unavailable]	
		Thread.run() line: 748	
	Daemon System Thread [TimerQueue] (Suspended)	
		Unsafe.park(boolean, long) line: not available [native method]	
		LockSupport.park(Object) line: 175	
		AbstractQueuedSynchronizer$ConditionObject.await() line: 2039 [local variables unavailable]	
		DelayQueue<E>.take() line: 211	
		TimerQueue.run() line: 174 [local variables unavailable]	
		Thread.run() line: 748 [local variables unavailable]	
	Thread [DestroyJavaVM] (Suspended)

So many threads/daemons are waiting for ReferenceQueue$Lock, some are waiting for TaskQueue and some seem active. Is there anything I can do to debug this further?

@jonasstein or some developer: could you please reopen this issue?

125m125 · 2017-10-05T22:44:01Z

All but one Thread are daemons, which are not blocking termination. The only non-daemon Thread is this one:

Thread [pool-4-thread-1] (Suspended)	
		Unsafe.park(boolean, long) line: not available [native method]	
		LockSupport.park(Object) line: 175	
		FutureTask<V>.awaitDone(boolean, long) line: 429	
		FutureTask<V>.get() line: 191	
		DefaultTaskExecutor.runInJavaFXThread(Callable<V>) line: 32	
		JabRefFrame.lambda$2() line: 665	
		310023215.call() line: not available	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).run() line: 266	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$201(ScheduledThreadPoolExecutor$ScheduledFutureTask) line: 180	
		ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run() line: 293	
		ScheduledThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1149	
		ThreadPoolExecutor$Worker.run() line: 624 [local variables unavailable]	
		Thread.run() line: 748 [local variables unavailable]

It is located under there: https://github.com/JabRef/jabref/blob/master/src/main/java/org/jabref/gui/JabRefFrame.java#L665

tobiasdiez · 2017-10-06T06:40:44Z

@michaellass thanks to a quick fix by @125m125 the issue should be now resolved in the latest development version

michaellass · 2017-10-06T18:53:21Z

This indeed fixes the issue in most cases but there is still a corner case left: When exiting JabRef while the statistics dialog is open, the following error is printed to terminal and JabRef does not exit:

[timer] ERROR org.jabref.gui.util.DefaultTaskExecutor - java.util.concurrent.ExecutionException: java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = JavaFX Application Thread

Siedlerchr · 2017-10-06T18:55:04Z

You have to wrap the command in SwingUtilities.invokeLater

The dialog to ask for collecting anonymous statistics needs to be created in the Swing EDT. Do so using SwingUtilities.invokeLater(). This is a follow-up on 7ef2b3a and should finally fix JabRef#2955.

michaellass · 2017-10-06T19:54:56Z

@Siedlerchr Since I have little to no experience with developing with Swing and JavaFX, could you check if PR #3272 is what you suggested? It works fine here and fixes the issue. As a side effect, it disables all user inputs in the main window while the dialog is open.

Siedlerchr · 2017-10-06T20:29:47Z

It looks good from my side. The blocking is okay, as it is defined as a kind of modal dialog.

The dialog to ask for collecting anonymous statistics needs to be created in the Swing EDT. Do so using SwingUtilities.invokeLater(). This is a follow-up on 7ef2b3a and should finally fix JabRef#2955.

The dialog to ask for collecting anonymous statistics needs to be created in the Swing EDT. Do so using SwingUtilities.invokeLater(). This is a follow-up on 7ef2b3a and should finally fix #2955.

jonasstein · 2017-10-31T22:37:16Z

still marked as waiting-for-feedback
it works in

JabRef 4.1-dev--snapshot--2017-10-31--master--1ebdea452
Linux 4.12.12-gentoo+ amd64 
Java 1.8.0_152

Thank you.

douglasrizzo · 2018-12-27T19:25:12Z

I am on Manjaro Linux 18.0.1 "Illyria". I've installed JabRef 4.3.1 through the AUR. I have noticed through top that all JabRef instances I start are not being terminated when I close the application window or through the Ctrl + Q shortcut. If I start JabRef multiple times after turning on my computer, all instances stay in memory until I kill them.

When I run JabRef through a terminal, either through the jabref or java -jar /usr/share/java/jabref/JabRef-4.3.1.jar commands, I get the following log when the program starts.

17:14:44.170 [AWT-EventQueue-0] INFO  org.jabref.logic.importer.OpenDatabase - Opening: /home/user/Documents/JabRef/Library.bib
File: grouptree.fxml not found, attempting with camel case
File: grouptree.css not found, attempting with camel case

Nothing else prints when I close the window and the terminal stays hanged until I hit Ctrl + C.

To be thorough, I've just downloaded JabRef version 4.3.1 from the releases page here on GitHub and exactly the same behavior occurs. If it is of any help, I have a library with roughly 600 items.

Output of java -version:

openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-b26)
OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)

douglasrizzo · 2018-12-27T22:26:17Z

I fixed the issue by unmarking the checkbox related to collecting and sharing telemetry data, in the General tab of the Preferences window. I saw this issue was mentioned in a few pull requests related to usage statistics, decided to try it and it worked.

Siedlerchr · 2018-12-27T22:31:52Z

Please try the latest development version in case you encounter any problems. Please remember to create a backup of your Bib file before trying out the new version

shichuzhu · 2019-11-21T06:56:35Z

I fixed the issue by unmarking the checkbox related to collecting and sharing telemetry data, in the General tab of the Preferences window. I saw this issue was mentioned in a few pull requests related to usage statistics, decided to try it and it worked.

Just tested with
JRE 1.8.0_231
Ubuntu 18.04.3 LTS
JabRef 4.3.1

The problem still exists. And unchecking "collecting and sharing telemetry data" does solve the problem.

Siedlerchr · 2019-11-21T07:40:45Z

@shichuzhu Please try the latest develioment version from 5.x..
Version 4.x is no longer supported. http://builds.jabref.org/master/

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

jonasstein closed this as completed Jul 4, 2017

125m125 mentioned this issue Oct 5, 2017

Wait to ask to collect anonymous statistics in JabRefExecutorService to allow jvm to terminate #3266

Merged

4 tasks

michaellass mentioned this issue Oct 6, 2017

Open statistics dialog from correct thread #3272

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Jabre-4.x does not exit cleanly #2955

Jabre-4.x does not exit cleanly #2955

jonasstein commented Jul 2, 2017

Siedlerchr commented Jul 2, 2017

Siedlerchr commented Jul 4, 2017

jonasstein commented Jul 4, 2017

michaellass commented Oct 5, 2017

125m125 commented Oct 5, 2017 •

edited

Loading

tobiasdiez commented Oct 6, 2017

michaellass commented Oct 6, 2017

Siedlerchr commented Oct 6, 2017

michaellass commented Oct 6, 2017

Siedlerchr commented Oct 6, 2017

jonasstein commented Oct 31, 2017

douglasrizzo commented Dec 27, 2018

douglasrizzo commented Dec 27, 2018

Siedlerchr commented Dec 27, 2018

shichuzhu commented Nov 21, 2019

Siedlerchr commented Nov 21, 2019

Jabre-4.x does not exit cleanly #2955

Jabre-4.x does not exit cleanly #2955

Comments

jonasstein commented Jul 2, 2017

Siedlerchr commented Jul 2, 2017

Siedlerchr commented Jul 4, 2017

jonasstein commented Jul 4, 2017

michaellass commented Oct 5, 2017

125m125 commented Oct 5, 2017 • edited Loading

tobiasdiez commented Oct 6, 2017

michaellass commented Oct 6, 2017

Siedlerchr commented Oct 6, 2017

michaellass commented Oct 6, 2017

Siedlerchr commented Oct 6, 2017

jonasstein commented Oct 31, 2017

douglasrizzo commented Dec 27, 2018

douglasrizzo commented Dec 27, 2018

Siedlerchr commented Dec 27, 2018

shichuzhu commented Nov 21, 2019

Siedlerchr commented Nov 21, 2019

125m125 commented Oct 5, 2017 •

edited

Loading