Jabref: Memory leak (?) when browsing bibtex file with editor open

[shitikanth]

JabRef development version on Mac OS X 10.11.4.

Steps to reproduce:

1. Open a small bib database in JabRef. The one I was working with had 19 entries.
2. Open the entry editor by double-clicking on any entry in the table, or through the menu (BibTex > Edit Entry).
3. Move focus back on the main table by selecting an entry.
4. Keep pressing up/down arrow keys and watch the memory usage grow from ~50MB to 2 GB and the number of threads owned by JabRef grow from 27 to over 2000.

Screenshots from activity monitor

and visualvm

If you are looking at the second chart, you are probably wondering what happened at the end that made the memory/threads stop growing. That was because at this point JabRef had apparently given up on trying to follow which entry I was trying to edit and stopped updating the entry editor altogether.

[shitikanth]

As far as I can tell, this was introduced in #2075 when the entry editors cache was removed.

We should either bring back the cache, or make sure that when a new EntryEditor object is created, the previous one is closed cleanly. I am guessing that there are some threads that still have access to the old EntryEditor objects and that is why they are not getting GC'd.

[stefan-kolb]

Nice catch! 👍

[shitikanth]

Thanks, @stefan-kolb.

I have traced the issue back to the microba library that is used to make the DatePickerButton in the EntryEditor.

[tobiasdiez]

Can we create the datepicker only when the button is clicked?

[shitikanth]

Microba's DatePicker class comes with the button. So, afaict, doing that would require hacking with the internals of the library.

[matthiasgeiger]

We could evaluate to switch to https://github.com/LGoodDatePicker/LGoodDatePicker

[koppor]

...or switch to JavaFX for that panel...

[matthiasgeiger]

Are we ready to include Java FX in the next (3.7) release?

[koppor]

I'd say "yes". --> DevCall 😇

[shitikanth]

I was wrong about this issue being entirely due to microba's DatePicker. There _was_ a memory and thread leak in the DatePicker class, but the issue in JabRef persists even after all references to microba are removed.

(Notice how there is no thread leak now.)

Also, I think that the issue in microba was fixed in later versions.

[koppor]

I could not withstand and to play around a bit. My observation: it is not related to the duplicate checker and possibly not related to the event bus (even though I disabled it in branch fix_2166).

I tracked it down to the BibLaTeX mode and the "Other fields" tab. @shitikanth Do you also use the biblatex mode or the plain bibtex mode?

[grimes2]

The thread leak is only in Biblatex mode, consistent with the DatePicker postulate. The memory leak is in Bibtex and in Biblatex mode. It happens also with a database with only two empty entries.

[shitikanth]

@koppor, I was using biblatex mode, but for me the problem happens in BibTex mode too. Looking at the heap dump, I can see over 200 instances of EntryEditor with a bib file of 19 entries.

Analyzing the heap dump, one possible issue I found was with the global search bar. We add the fields of a new entry editor as listeners of the global search bar, but we never remove them. So, these fields stay accessible from JabRefFrame.

I removed the highlighting features from EntryEditor, but still memory leak. And now, the only path to GC root visualvm would find for me is this one:

I don't really understand what MultiResolutionToolkitImage class is or why it holds a reference to JTabbedPane.

[shitikanth]

Here is a set of steps that fix the memory leak, at least on Linux:

• Update microba to latest version
• Remove EntryEditor as a listener to Entry when it is about to be removed
• Remove search highlighting for the fields of the EntryEditor

(Ref. 554523d)

What is weird is that these steps do not fix the problem on OSX, where there is still a memory leak as i pointed out in the previous comment.

[grimes2]

Windows 10
I can confirm, that in BibTeX mode the memory leak is fixed with the set of steps (I didn't update microba to latest version, so I still have a memory leak with BibLaTeX databases)

[koppor]

@matthiasgeiger Reading https://github.com/tdbear/microba/commit/9a67c143abb9887964085c3709392861ae6fbb35, maybe we should really switch to https://github.com/LGoodDatePicker/LGoodDatePicker - it is also available on maven central (in contrast to microba).

[grimes2]

JabRef 3.7dev--snapshot--2016-10-18--master--f3ecde1
windows 10 10.0 amd64
Java 1.8.0_101

In BibLaTeX mode, there is still a small memory leak. I've tested with complex.bib.

I've investigated the issue with following experiment:

• File > New BibLaTeX database
• First entry: BibTeX > New entry > Set (because there is no date field with a DatePicker)
• Second entry: BibTeX > New entry > Set
• 50x Next entry
• No memory leak

A possible interpretation: microba is still buggy (memory leak).

It's probably a good idea to switch to LGoodDatePicker.

[shitikanth]

In BibLaTeX mode, there is still a small memory leak. I've tested with complex.bib.

@grimes2 I can't replicate this on Ubuntu 16.04, Java 1.8.0_102.