Runaway process, High CPU and RAM usage for large databases when autocompletion preference is enabled

[umuen]

JabRef version JabRef 5.2--2020-09-29--2d92025 on Mac OS X 10.15.7

• Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

Symptoms:

• Starting JabRef results nearly always in runaway behaviour, laptop cooling system kicks in, a 'top' shows 600-800% processor used by jabref. Sometime this starts directly, sometimes only after a few minutes.
• Then finishing the programme with "Quit" sometimes closes window (sometimes not), but process still active
• has to be killed via "Force Quit" that often shows programme as "not reacting"

Steps to reproduce the behavior:

1. switch on JabRef
2. a normal search within a database normally triggers behaviour
3. sometimes also just clicking on an entry triggers it

Behaviour was always there, for all developer versions of jabref 5.2 and 5.1 that I tried. Also for Mac OS X 10.15.6.

Seems strongly to depend on database size. For 50 entries it seems ok, but for 500 not. My standard data base is more like 10000.

[Siedlerchr]

Thanks for the report. I could partially reproduce this. I tested with a library of around 6500 entries. It seems to be related to the search. When I search the cpu goes up, but stil okay, but when I then cancel (or X the search), my laptop fan also goes high. Trying to quit it seems not to work either. Somehow a thread is still active in the backgrond.

When debugging, I see Authorlist.parse is called from several threads and it seems to be related to the AutoCompleter

[chrisdebrunner]

I see a similar problem with Jabref 5.1 under RHEL 7.9. I start JabRef and it uses 5-10% CPU after startup. Then I type into the search field, and CPU jumps to 600-700% and stays there even after I cancel the search (press the "x" at the right end of the search box) and if I close the GUI by clicking the close box in the upper right. I have to kill the JabRef process from the command line.

[christophe-gouel]

I have exactly the same issue with JabRef 5.1 under Windows 10 and a library of around 5000 entries. A search (or just some waiting time) starts the problem and closing JabRef normally is not enough.

[Siedlerchr]

Thanks all for the reports. Does it help if you disable the autocompletion in the preferences?

[christophe-gouel]

Yes, it seems to solve the problem. Thanks.

[umuen]

Yes, indeed, everything seems fixed on my machine when autocompletion is disabled. thanks uwe

…

On 4. Nov 2020, at 18:31, Christoph ***@***.***> wrote: Thanks all for the reports. Does it help if you disable the autocompletion in the preferences? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[chrisdebrunner]

I also did not see the problem anymore after disabling autocompletion.

I was glad to learn that autocompletion could be turned off, as it would pop up an annoying menu and disable typing whenever I typed a { or } in the Title field (and presumably the other affected fields).

Thank Siedlerchr for proposing this simple workaround.

--Chris

[christophe-gouel]

Since Nov 2020, I have used JabRef without autocompletion and was very satisfied with it. To check if the issue was still relevant, I have just reactivated the autocompletion. After 30 seconds, the processors were fully saturated and closing JabRef (5.2) was not enough since it stays open in the background.

So the issue is still there, but if people are happy to work without autocompletion, which is my case, then this is not a pressing issue.

[chrisdebrunner]

I was able to reproduce this error under RHEL 7 with JabRef 5.2, and under Mac OS X 11.1 with JabRef 5.2. Note that under RHEL 7, JabRef 5.2 crashes if I start it by executing ${JabRefRoot}/bin/JabRef, so I instead execute ${JabRefRoot}/lib/runtime/bin/JabRef.

While I no longer use autocomplete and this issue does not impact me, I would recommend leaving it as an issue, but perhaps down weighting its importance. It seems to me that autocomplete should either be removed or this issue should be fixed.

[Mixopteryx]

I have experienced this error for a while and now reproduced this error with a library with 1202 entries with the following versions:

JabRef 5.3--2021-07-05--50c96a2
Windows 10 10.0 amd64 
Java 16.0.1 
JavaFX 16+8

and

JabRef 5.4--2021-09-13--fbfa35b
Windows 10 10.0 amd64 
Java 16.0.2 
JavaFX 17+18

In particular what happens is that:

• Jabref CPU & memory usage runs away during usage
• Closing JabRef after CPU leaves a lingering process that I must close via Task Manager
• Disabling autocomplete in the entry editor seems to remove the problem.

[ilippert]

This links to #8906

[HoussemNasri]

Hello everyone, please try this build and see if the problem persist.