Jabref: Jabre-4.x does not exit cleanly

[jonasstein]

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

[Siedlerchr]

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]

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]

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]

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]

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]

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

[michaellass]

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]

You have to wrap the command in SwingUtilities.invokeLater

[michaellass]

@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]

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

[jonasstein]

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]

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]

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]

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]

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]

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