Large memory usage on Windows 7, freezes on Fedora 24

[CsatiZoltan]

JabRef version 3.6 consumes a lot of memory under Windows 7 (more than 500 MB, see the attached screenshot) and sometimes it freezes (than it's allocating more and more, unbounded. I killed the process after 1500 MB). On Fedora 24 freezes much more often. The former versions were totally stable on Windows 7.

[stefan-kolb]

Thank you for your report 👍
This should be fixed in current master. Please try the latest build from http://builds.jabref.org/master.

[CsatiZoltan]

After installing the latest build from your link, it didn't become better. When I wanted to close it, it didn't exit, but the allocated memory was not freed (see the screenshot). I had to kill the process.

[stefan-kolb]

Can you give us some steps to reproduce the memory leak?

[CsatiZoltan]

I just opened it and added an article. Here is the .bib file.
SaddlePoint.zip

[stefan-kolb]

Ah thanks great! We will investigate this!

[grimes2]

500 MB Memory is normal for JabRef. Your system seems to have only 2 GB RAM.

[CsatiZoltan]

No, my system has 16 GB of RAM.

[Siedlerchr]

Do you have the 64bit java runtime environment installed?

[koppor]

Refs #2166 #2175

[tobiasdiez]

I can confirm at least the large memory footprint. After opening a normal db (mine has 500 entries and a few groups) JabRef eats only 200 MB of RAM. Now open the entry editor and run through a few entries (using the arrow keys so that a new entry editor is generated for the entries). Result: over 1 GB of RAM usage. Btw: the same db with 3.6 only needed < 100 MB RAM.

[stefan-kolb]

• The spikes are running through the entries.
• Strangely enough the Heap is growing continuously without any interaction with the program.
  

As long as I keep the entry editor closed nothing happens to the RAM.

[grimes2]

JabRef 3.7-dev--snapshot--2016-11-08--master--fffad83
windows 10 10.0 amd64
Java 1.8.0_111

I can't reproduce. For me this issue was fixed in #2175.

Is this issue valid for BibTeX or BibLaTeX mode?

[matthiasgeiger]

Both.