Jabref: Search crashes completely on mid-sized database

Created on 27 Apr 2018  路  9Comments  路  Source: JabRef/jabref

Versions:
Issue persists in dev snapshot: https://builds.jabref.org/master/JabRef-4.3-dev--snapshot--2018-04-26--master--7629b3171.jar

Tested on Windows 7 with Java x64 Build 1.8.0_162-b12

Issue:

On a database with about 2000 entries, most of them with associated PDFs, the search box behaves even worse in 4.2 than it did in 4.1.

Problems are:

  1. Random duplication of entered search strings (see issue #3921 )
  2. Random lockups of the complete search box (no new text can be entered, old text cannot be deleted, no text can be marked)
  3. Random vertical shifts of the already entered characters as if a new blank line was added.

Problems 1) and 2) were already present in 4.1, Problem 3) seems to be a new addition of 4.2. I also have the feeling that the crashes will come faster now, on average it takes only 3-4 searches until something bad happens and you have to restart JabRef entirely.

bug 馃悰

All 9 comments

I really cannot reproduce this with Win10 and a bib database with '>6.000 entries.
It could be a memory problem. How much RAM do you installed in your machine?
Do you have the entry open when searching`? Probably at the General Tab?
When you close the entry editor, or switch to another tab the search should be way faster.

For me it looks like this is still some double generation or reception of events.
It feels like it is occuring more often when load is on the computer and if you type fast.
Strangely enough afterwards it does not recover from this duplictaed events, which I would expect if I delete the search term.
I also experience that after deleting the term te cursor stays on the left forever.
I think we had this bug before and "fixed" it.
It is here again.

The search timer waits 400 ms until it executes the search. When you start typing the current search gets cancelled and the timer resetted.
I think it could maybe due to the richtextfx thing which was also used for the source tab.

I am experiencing this exact same bug. The database file that I use has about 13,000 entries in it. On windows 10. This bug existed for me since 4.0, and seems to be the same or worse with 4.2. It seems to occur seemingly randomly. Having an entry opened or closed on any particular tab does not seem to be a factor in the bug occurring.

I also don't think this is a memory issue, machine being used has 8gb ram, and only about half of that is ever taken up at any one time while using jabref.

To be clear, the speed of search is not an issue, it is simply the search box becoming bugged and unusable when entering a search string, usually after a couple strings have been entered one after another.

I'm experiencing a similar issue with JabRef 4.2 running on Ubuntu 16.04.
While searching a database of > 2,000 entries is fine, as soon as I double click on an entry after a search and the input window opens, JabRef freezes.

Actually, JabRef freezes as soon as I open an entry a second time (without any prior search or filtering). This did not happen with JabRef 4.1.

Correction: It was the Look&Feel issue on Linux. After changing the default look and feel to the metallic theme, everything works fine (see #3997)

Everyone that has this problems: could you please update your Java to the latest version (Version 8 Update 172). I did experience way less problems with this version. The old Java 162 has a CPU leak that causes the events to duplicate etc.

For me that's not it though. I'm running 172. For me it was the Look&Feel issue (see #3997).

This should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks!

Thank you. Yes in Jabref 4.3.1 the issue is fixed for me on Ubuntu 16.04.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

caugner picture caugner  路  3Comments

thorstenwagner picture thorstenwagner  路  4Comments

jonasstein picture jonasstein  路  3Comments

tobiasdiez picture tobiasdiez  路  4Comments

lenhard picture lenhard  路  4Comments