Open Doublonmousse opened 7 months ago
Siedlerchr
commented
7 months ago Hm that should not happen. We look into it. Btw, JabRef keeps multiple backups. Can you verify if any of the older backups are available and non empty? https://docs.jabref.org/advanced/autosave#where-can-i-find-the-backup-files
Doublonmousse
commented
7 months ago I checked and the backups are there and are non empty.
Trying to kill manually jabref to reproduce the bug with unsaved changes and recovering doesn't seem to reproduce the issue, maybe I will wait for a crash to recheck then ... (and maybe open jabref with logs/debug enabled to capture such an event the next time it happens).
In the meantime, maybe I should rename the issue to add a warning message should the backup be empty, very small or very different compared to the bib file on disk) and the user clicks on the "restore backup button" to check the backup before proceeding, as that would be more productive.
koppor
commented
7 months ago Do you have any idea which content you put into the entry editor so that JabRef cracked during writing the contents?
Could you tey to check the log files of JabRef? There should be an exception recorded. That could give us some hints...
Doublonmousse
commented
6 months ago Oh it's not a permanent log file is it ? On 5.12 the log file is overwritten on each jabref boot (so I'm unable to find any bug info as it's gone once I relaunch jabref after a crash).
This time I think I have a way to reproduce the bug (with logs as well). I'm kinda sorry for the long wait (and the original issue that was not detailed enough, it's just that these things happen when I use jabref, so when I'm busy, this time I happened to see a pattern)
The input jabref failed on is this one (ASCII clipboard content viewed from clipboard viewer)
bplist00¢..¡._.Lhttp://www.amazon.com/exec/obidos/ASIN/0521437997/ref=nosim/ericstreasuretro¡._..Chaos in Dynamical Systems....\^...............................|This is copied from the reference title Chaos in Dynamical Systems. seen here Shadowing theorem
To reproduce, just paste this clipboard into a new article entry, in the title section, do not save and wait for jabref to crash (occurs in less than a minute).
Then, on reboot, the backup will be empty with this error message
Jabref will also fail to reload the library if loaded at this point.
The stacktrace shown in that window is the following :
java.lang.NullPointerException
at java.base/java.util.Objects.requireNonNull(Objects.java:233)
at java.base/java.util.Optional.flatMap(Optional.java:290)
at org.jabref@5.12.60000/org.jabref.gui.dialogs.BackupUIManager.showRestoreBackupDialog(BackupUIManager.java:50)
at org.jabref@5.12.60000/org.jabref.gui.importer.actions.OpenDatabaseAction.loadDatabase(OpenDatabaseAction.java:221)
at org.jabref@5.12.60000/org.jabref.gui.importer.actions.OpenDatabaseAction.lambda$openTheFile$1(OpenDatabaseAction.java:193)
at org.jabref@5.12.60000/org.jabref.gui.util.BackgroundTask$1.call(BackgroundTask.java:60)
at org.jabref@5.12.60000/org.jabref.gui.util.DefaultTaskExecutor$1.call(DefaultTaskExecutor.java:161)
at org.jabref.merged.module@5.12.60000/javafx.concurrent.Task$TaskCallable.call(Task.java:1399)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)The stacktrace that mac os gives for the crash is the following
I've also linked this stacktrace as a txt file for good measure
Doublonmousse
commented
6 months ago This crash puts jabref in a state where the backup is not accessible (clicking on review backup fails with null), not restoring doesn't open the file either, but restoring for backup does not error and overwrite the file with an empty one instead with no error message or exception catching to prevent it
Siedlerchr
commented
6 months ago Having a mac here as well, I cannot reproduce this in the latest dev version. https://builds.jabref.org/main/ (Arm suffix is for. mac m1) Do you have on screen keyboard or something else activated? Could you maybe do a short screen record with the steps?
Doublonmousse
commented
6 months ago I've re tested on the latest dev version and it still happens.
Somehow, I've only been able to make it crash 3 times with --debug activated and the output wasn't too useful (message about a paste action immediately followed by zsh filled before having the mac os crash pop up appear. Is there a --tracing option to have more informations about the crash ? Because at the moment I don't see anything substantial)
The thing is I'm unable to reproduce the bug in a fully reproducible way (as the crash only occurs sometimes even though the chain of action is the same).
For now the steps that (sometimes) made jabref crash are the following
Create a new library with a non empty element then save it
add a new entry
copy a link from a website into textedit (the mac os text editor) then from textedit to a field of the new entry (for now I've tested with the link from before, seems to work a little better if part of the link is copied instead of the whole link)
wait (do not save)
(maybe) crash
after relaunching the window, if you click the Review backup this will fail with an error message, and if you do decide to Restore from backup, then the operation successfully overwrite your whole .bib file with a new clean one with no entry. Lastly, if ignore backup is clicked, jabref tries to reload the library but get stuck in an infinite loop and never loads.
If the app crashes upon pasting this, it will do some at most 2 times before doing the same action doesn't seem to trigger the crash anymore on the same library file.
I don't know how actionable this information is, I do think there could be more things done to prevent overwriting your perfectly valid bib file by a blank one : I believe the Restore backup should fail like the Review backup button does (do the same checks on that button and abort the backup restoration if these checks fail).
ThiloteE
commented
1 week ago @Doublonmousse would you be so kind to provide the broken .bib file?
Also, in the screenshot you show, you partially seem to deal with UTF16 encoded text. JabRef bibfiles only supports parsing UTF8 encoded text nowadays. Maybe sometimes you copy and paste UTF16 encoded text into your bib-file? Does that cause the crash?
Doublonmousse
commented
1 week ago @Doublonmousse would you be so kind to provide the broken
.bibfile?Also, in the screenshot you show, you partially seem to deal with UTF16 encoded text. JabRef bibfiles only supports parsing UTF8 encoded text nowadays. Maybe sometimes you copy and paste UTF16 encoded text into your bib-file? Does that cause the crash?
I don't really have a non working .bib file. The issue is more that jabref sometimes crashes in a particular way whilst editing the bib file that makes the recovery process not work and may override the bib file with an empty one).
I still don't have a fully reproducible example either (and I haven't used jabref enough on more recent versions to say whether this is fixed or not).
So it's overall very obscure (and when it did crash it wasn't necessarily immediate either).
I feel like having some additional cautionary check when using the recovery dialog would be more than enough of a fix (make it so it's not possible to override the current bib file with an empty backup).
Everytime it did crash in this way, there wasn't actually a data loss (except maybe for the entry on which it did crash).
koppor
commented
1 day ago
JabRef version
5.12 (latest release)
Operating system
macOS
Details on version and operating system
Sonoma 14.2, M2
Checked with the latest development build (copy version output from About dialog)
Steps to reproduce the behaviour
.bibfile ....bibfileAppendix
EDIT : There is actually a
review backupbutton.I think there should be a warning inviting to review the backup before proceeding if it's empty or small compared to the current
.bibfileIf I hadn't saved my
.bibfile in a local.gitrepository, it would have been erased multiple times by Jabref.This all happened on an external drive