Keepassxc: KeepassXC (Linux) crashing on Apply/OK/Cancel

[rlando1]

Expected Behavior

KeePassXC should save the data (or not in the case of cancel), and return to the database tree with all the entries

Current Behavior

When editing an entry, upon hitting any of the below buttons, KeepassXC will crash without saving. This happens approximately every other time trying. In other words, I can open the database and save one entry, but the next one will crash it.
_Apply, Cancel, OK_
Edit: Cancel does appear to be working, so long as I "Close without saving"
Edit 2: Cancel works when I don't make a change. However, when I make a change using Apply, then hit Cancel to exit, it will crash. (In this situation, the change will be saved to the database with the Apply action)

Possible Solution

None

Steps to Reproduce

1. Open database
2. Edit an entry
3. Save entry
4. Open another entry
5. Save entry

Context

This makes using KeePassXC very frustrating. Windows does not appear to have this issue (and Linux hasn't in the past either)
I have tried disabling the browser extension, restoring settings to default, moving all entries to a new database, using the development version, and the current app package.

Debug Info

KeePassXC - Version 2.5.1
Revision: 0fd8836
Distribution: Snap

Qt 5.9.5
Debugging mode is disabled.

Operating system: Ubuntu Core 18 (Went from Ubuntu GNOME to KDE Kubuntu)
CPU architecture: x86_64
Kernel: linux 5.3.0-23-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey
• Secret Service Integration

Cryptographic libraries:
libgcrypt 1.8.1

Libraries:

• LIBS

[Nothing4You]

moved my comment to #3810

[rlando1]

Moving entries to different folders works, and saves without any issues

[rlando1]

I have found that the package provided through the traditional Ubuntu apt repository works perfectly. To me, this implies an issue introduced after _Version 2.4.3_
It's details below:

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.12.4
Debugging mode is disabled.

Operating system: Ubuntu 19.10
CPU architecture: x86_64
Kernel: linux 5.3.0-23-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (only unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.4

[blueorignal]

I can confirm this behavior on Ubuntu 18.04.3 LTS. The behavior is the same using either the official keepassxc PPA (ppa:phoerious/keepassxc) install or using the official .AppImage from the keepassxc website. This is for the current version 2.5.1.

I've noticed this occurring over the last few versions. Once keepassxc crashes, if you relaunch the program and redo the same action it usually succeeds. However it is still prone to crash later when pressing ok, cancel, apply or pressing esc.

Please let me know if you require any additional details.

[ba32107]

@rlando1 your last comment suggests that you downloaded KeePassXC through apt, and it installed 2.4.3 - is this correct? That is weird because I'm also using the apt version and I got 2.5.1.

I am unable to reproduce the issue though.

[blueorignal]

@ba32107, I think @rlando1 is installing from the default Ubuntu PPA (managed by Canonical). This would result in version 2.4.3 being installed. I installed from the official keepassxc PPA (ppa:phoerious/keepassxc) which results in the current version, 2.5.1, being installed.

@rlando1, please correct me if I am mistaken.

[rlando1]

@blueorignal That is correct. The version that works for me is the version from the Canonical PPA at 2.4.3
I just tested the official KeePassXC PPA (ppa:phoerious/keepassxc) which has version 2.5.1 and experienced the same issue as with the AppImage, and Snap.

[ba32107]

I was able to reproduce this just now with my own database (earlier I was testing with a dummy test DB). The difference is that in my own database, the encryption time is set to a higher value (meaning it takes a few seconds to save). I'm pretty sure the issue is related to this.

This is related to https://github.com/keepassxreboot/keepassxc/issues/3742, I have seen a few other problems caused by the same issue. Essentially, you are able to perform certain actions while the DB is being opened / saved, which can cause crashes. It should be addressed in a generic way that solves all problems.

[droidmonkey]

Yes agree these crash issues are all related to doing "something" while the database is saving

[blueorignal]

In my case the crashes seem to follow an on/off/on/off pattern. If I open up keepassxc and create and entry, press ok, the program crashes. If I then re-openkeepassxc and create the same entry, press ok, the program does not crash. Again if I close keepassxc and try again the program will crash,etc.

This crash, not crash, crash, not crash behavior seems to occur opening or closing keepassxc or when working on multiple entries i.e. entry 1 (ok), entry 2 (crash), re-open keepassxc, entry 2 (ok), entry 3 (crash), etc.

I hope that makes sense, I'm not sure my description is as clear as it could be.

[ThomasWMarshall]

I'm getting something very similar. I'm running 2.5.1-1ppa1~bionic1 from lp_ppa_phoerious_keepassxc-bionic-main.

I'm running KDE Neon which is based on Ubuntu 18.04 LTS.

If I launch KeePassXC from terminal, I can see that a segmentation fault causes the crash.

I seem to be able to create entries just fine, but editing them causes a crash.

I should also mention that, for what it's worth, the entries are successfully edited and they do save, even if the program crashes.

[droidmonkey]

That's interesting, the fact they saved means the crash is occurring AFTER the database save routine is completed. This is good information.

[blueorignal]

Just to confirm, if the program crashes, the database is not updated.

As an example - if I edit an existing record, add a new note and click "Ok", keepassxc crashes and when reloading the databases, the updates have not been recorded.

[rlando1]

@blueorignal That is correct for me. My crashes cause the database to not save.
I can also confirm the "on/off/on/off pattern" that @blueorignal is seeing. It seems like the first save of the program running always works. Subsequent ones have a chance of crashing.

I also just received this prompt upon hitting "Ok" in my testing:

The database file has changed and you have unsaved changes.
Do you want to merge your changes?

Could be an unrelated message, but I find it interesting combined with the "On/Off/On/Off" pattern

[ThomasWMarshall]

Perhaps my issue is distinct. Shall I open a new issue?

edit: @droidmonkey I compiled with debugging symbols and induced the error while running under Valgrind which claims that my segfault occurs on line 805 of Entry.cpp in Entry::beginUpdate which reads

 m_tmpHistoryItem.reset(new Entry());

I have the whole stack trace if you want it.

Maybe this could help isolate the issue or establish if I'm experiencing the same bug as the others.

[droidmonkey]

@ThomasWMarshall Yah that issue has been around a long time. This usually happens when you have an older database. The cause is unknown and can be random.

[ThomasWMarshall]

@droidmonkey Gotcha. Is there an open issue?

[droidmonkey]

There is not but this one suffices. #2538 names the issue in the first post.

[ThomasWMarshall]

@droidmonkey I have discovered that my issue is indeed the same as that described in #3890.

[blueorignal]

@droidmonkey, your comment about "old databases" may also be a clue. The database that I am referencing is years old and has been used through many versions of keepassxc and indeed keepassx and keepass prior to that.

Do you have any suggestions for creating a new database and transferring across all the existing items? If I simply create a new database and copy and paste all the groups and records across would that likely fix the issue? Or do you think that I would need to export the old database, create a new one and then re-import?

Obviously the first option would be preferred (as I am spectacularly lazy) but I wonder if this would be enough to remove any "crufy garbage" from the original database.

Any thoughts or suggestions would be welcomed.

[rlando1]

@blueorignal, unfortunately I have tried recreating my database a couple of times. I copied and pasted groups and entries as you said, and it doesn't seem to have solved the issue.
I can try out the export idea if you would like.

[blueorignal]

@rlando1 I would greatly appreciate if you could try the experiment of exporting keepassxc data to CSV, creating a new database and then re-importing the data.

I plan to do this experiment myself, but I am out of town for the week without access to my main machine.

Thank you for your offer.

[droidmonkey]

@ThomasWMarshall is looking into this bug right now and may have found some clues. My assumption is that it is due to a bad history entry that causes issues. We are narrowing it in. Exporting to CSV and reimporting would clear your entry history (and UUIDs) so it would indeed be a good test. Be aware that I wouldn't keep using the reimported database because you may lose information. CSV is not complete.

[rlando1]

@droidmonkey, @blueorignal: I've tested the export to csv, then re-import. It seems to have the same issue. I edit for a couple of times without issue, then it pops up and asks if I want to _merge or discard changes_. (Note, this doesn't happen every time, but I have seen this before. Could be unrelated)
I click merge, and I get this out put to console:

QWidget::setWindowModified: The window title does not contain a '[*]' placeholder
QFSFileEngine::open: No file name specified
Merge testname/testname with alien on top under Root
...
Merge Title/Title with local on top/under Group
Segmentation fault

It lists what looks like all my entries, but I removed those from this post

[droidmonkey]

ahhh so it is crashing during (or shortly after) the merge operation (for you). That is interesting. Could really use a stack trace of that.

[rlando1]

Okay very interesting development I just found @droidmonkey. This may not be the case with the others who are replicating this issue, however my database is stored in a cloud storage service called Tresorit. For this test I used the csv imported DB.
When I use the database from my local Downloads folder, it doesn't seem to have any save issues with my initial testing. I saved an entry 12 times in a row without crashing. However, when I use it in a Tresorit folder, it crashes very quickly. This is regardless of whether or not the "Safely save database" feature is enabled. And as previously stated, it does still work in older versions.

I'd be happy to help with a stack trace, however I'm not sure on how to do that (still new to this). If you could provide a link to how to do that with KeePassXC I'll give it a shot.

[droidmonkey]

This is similar to the "Crash in cloud folder" on macOS. I bet there is a weird timing and sync issue going on here. I save my database on One Drive on Windows and have never encountered a crash. Interesting indeed, likely an edge case that is triggered by a random combination of settings.

The best way to provide a stack trace is to run a snapshot build which enables that feature again: https://snapshot.keepassxc.org

[rlando1]

@droidmonkey I just saw that issue and was wondering the same thing.
I also use Tresorit on Windows (same folder etc) and don't have this issue. Seems to be an issue on on Linux (and potentially MacOS)
I tested out a few of those snapshots and found that the most recent snapshot (sort-of) works. I'll summarize the current state of my findings below:

Build 42085

• Crashes with "Safely save database file" _enabled_
• Doesn't crash with "Safely save database file" _disabled_

Build 41395

• Crashes regardless of "Safely save database file" setting

Release 2.5.1

• Crashes regardless of "Safely save database file" setting

Release 2.4.3

• _Does not crash_ regardless of "Safely save database file" setting

Seems to me the problem may have been mitigated in the latest build, although the status with Release 2.4.3 is obviously ideal
Is anyone else able to replicate these findings?

[droidmonkey]

Nothing changed in the code between 42085 and 41395

[blueorignal]

I just want to add that the user who is experiencing the issue is running on Linux and using Tresorit as well. I am fairly certain that this combination (Linux [Possibly MacOS] + Tresorit) is the root cause. However as to what is specifically driving the issue, I am uncertain.

[blueorignal]

TL;DR: For the moment, a work around that appears to be successful is to disable the "Automatically save after every change" option in settings.

After a bit more exploring I can report the following:

1) In settings, if I turn off "Automatically reload the database when modified externally", I can observe that a few seconds after making a change to a record, the Tresorit client syncs the change, and then keepassxc prompts the user with a "Do you want to reload the file that has changed". Conclusion - during the sync process Tresorit possibly touches/updates the database and it is the reloading of the database that causes the crash in keepassxc.

1. A work around that seems to avoid the crashes is to turn off the "Automatically save after every change" option in settings. Please note that I am making this recommendation with limited testing. You can still leave "Automatically save on exit" enabled and this doesn't seem to cause the crash.

I realize that this is not definitive, but I think it is worth investigating the hypothesis that the automatic reload of the databases file which is updated by the external file syncing app (Tresorit) is causing the crash.

[droidmonkey]

I wonder if there is an infinite recursion happening that is the cause of this crash. Save -> change detected -> reload -> save -> ....

[droidmonkey]

I think I found the cause of this issue.

[darkwing1]

Also got my first crash today after pressing Apply.
Ubuntu 18.04

[blueorignal]

@droidmonkey - I'm happy to test a pre-release for you if that would help. Thank you for following through with this issue.

[fra-san]

I'm probably experiencing the issue discussed here. After some testing, I'd summarize it as: on Linux, if I touch keepassxc's database and then I click on "Ok", "Cancel" (for both edited and untouched entries) or "Apply" (for edited entries), keepassxc crashes.
The changes proposed in https://github.com/keepassxreboot/keepassxc/pull/3991 don't seem to fix the issue.

Thanks to @rlando1 and @blueorignal I realized that my keepassxc database was being watched and synchronized by Drobox. Turning off Dropbox simply removed the crashing behavior completely.

Trying to make the issue easy to reproduce, I came up with this test case:

Environment: kvm-qemu virtual machine
Operating system: Arch Linux; KDE Plasma Version: 5.17.4; KDE Frameworks Version: 5.64.0; Qt Version: 5.13.2; Kernel Version: 5.4.2-arch1-1; OS Type: 64-bit
File system: ext4

Steps to reproduce:

• On a fresh system, install keepassxc from the official Arch Linux repository (whose version is currently 2.5.1, built using keepassxc-2.5.1-src.tar.xz).
• Start keepassxc.
• Create a database, always accepting the default options. I used test as database name and password, test.kdbx as database file name.
• Create a new entry. Again, I just filled "Name", "Username" and "Password" with the string test. Click "Ok".
• Open the "test" entry (entering entry view).
• Using a shell, cd to the directory the database is located in and run touch -m test.kdbx.
• In keepassxc, click "Cancel" to close the entry and go back to the entry list.

Actual behavior: keepassxc crashes. This happens 100% of the times. If you opened it by running keepassxc in a shell, while crashing it (only) prints out "Segmentation fault".

Expected behavior: the entry view closes and the entry list is shown.

Additional information:

• Version 2.5.1 --debug-info:

  KeePassXC - Version 2.5.1
  Revision: 0fd8836
  
  Qt 5.13.2
  Debugging mode is disabled.
  
  Operating system: Arch Linux
  CPU architecture: x86_64
  Kernel: linux 5.4.2-arch1-1
  
  Enabled extensions:
  - Auto-Type
  - Browser Integration
  - SSH Agent
  - KeeShare (signed and unsigned sharing)
  - YubiKey
  - Secret Service Integration
  
  Cryptographic libraries:
   libgcrypt 1.8.5
  

• Clicking "Ok" or "Apply" leads to a crash, too. In both cases, changes made to the open entry are not saved.

• If "Automatically reload the database when modified externally" in Preferences > General is unchecked, then, in entry view (for the aforementioned test entry):

  • If I touch the database, click "Yes" in the "File has changed" dialog (which asks "The database file has changed. Do you want to load the changes?"), and then click "Cancel" (or, equally, "Ok" or "Apply" after some changes), keepassxc crashes (and changes are lost).

  • If, after touching the database, I click "No" in that dialog and then "Cancel", "Ok" or "Apply", then keepassxc does not crash and gets back to the entry list and changes (in case of "Ok" or "Apply") are saved.

• Version 2.5.0 doesn't show the crashing behavior.

• Trying to narrow down my tests, I checked out and compiled a few commits from the develop branch (based on a brief look at the commit log):

  • 87ca7c7f7b84c361a00ee892232b139d60241d16 doesn't show the crashing behavior. However, if I touch the database before clicking "Apply" or "Ok" for an edited entry, then keepassxc returns to the entry list without saving any change and the edit is lost.

  • 22af66e3b586583b2d8493b524accfc546cddf32 shows the crashing behavior.

• I also tested 14b94d907da42d4dc6461922d70b3bd1280cfb92, which still shows the crashing behavior.

[droidmonkey]

Awesome thank you for the reproduction steps!

[droidmonkey]

@fra-san can you try my latest commit on #3991. I think I found the root cause this time.

[fra-san]

@droidmonkey The issue seems resolved, thank you! I tested both the steps from my previous comment and my usual setup (database synchronized by Dropbox), and keepassxc never crashed.

It looks like the database is not reloaded anymore after being simply touched, but I think I can confirm that it is reloaded as expected, and a proper dialog is displayed, when something actually edits it (e.g. a second, concurrent keepassxc instance).

[droidmonkey]

Yup that is by design with those changes. We shouldn't be triggering a full reload just because the time changes. It checks the checksum to make sure something actually changed.

[botanegg]

Seems resolved. It is not reproducing within 2 hours of database editing on 7821bffbf7190c8bfd095b645c5a0d74b29fb900
With touching on background too

[droidmonkey]

How do you like (or dislike) the entry/group view disabling on save and reload?

[botanegg]

How do you like (or dislike) the entry/group view disabling on save and reload?

Something like disabling Apply/Ok/Cancel button?
It looks good for me after #3941 fix will be merged

[fra-san]

How do you like (or dislike) the entry/group view disabling on save and reload?

At least with version 2.5.1 (and using a fairly high decryption time), after clicking "Ok" or "Apply", keepassxc already stays intermittently unresponsive for a few moments, likely until the save operation completes. I feel that having the window explicitly locked/grayed out provides a better experience.

Also, I don't think it'd be a great idea to allow the user to keep editing things before a save operation completes. True, this will hardly be an issue for the vast majority of users, but databases residing on remote storage and using a long decryption time may actually take longer to save than the amount of time it takes to the user to make several further small changes and click "Ok" again. I'd really dislike the idea of being presented with some "something went wrong and your changes could not be saved" message without being able to tell which changes have been saved and which have not (tough favicons and possibly other less important things may be an exception here).
I think that asynchronous, non blocking save operations might be offered as an option, but that should not be the default behavior.

[chaos-prevails]

I'm sorry to report, but I still sometimes have this issue with 2.5.2 on both computers when sharing a keepass file via nextcloud. I tried out different combinations of the settings "safely save database files" and "automatically save after every change" on both ends, but the results are not conclusive. I think it mostly happens when editing existing entries, not when creating a new entry. Sometimes keepassxc crashes, more often not (even if the merge request popup shows).

What is more severe is not the crash, but the password loss. This really happened already a couple of times when we started migrating to 2.5.1 (we are right now back at 2.3.x). The popup appears after the database has been reloaded in the background. I might be typing in another program at the same time,so I accidentally accept(ed) merge (even if I myself haven't edited the file) or discard. The result is that the newly added/edited password is lost on both ends.

There is only one "error" message (OpenType support missing for "Ubuntu", script 12).

Please let me know if I can do something else to narrow down this problem. We use keepassxc to share password files within our organization, and I really love it :)

Setup:
=== Computer A ===
KeePassXC - Version 2.5.2
Revision: 62cda9d

Qt 5.9.5
Debugging mode is disabled.

Operating system: Ubuntu 18.04.3 LTS
CPU architecture: x86_64
Kernel: linux 5.0.0-37-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey
• Secret Service Integration

Cryptographic libraries:
libgcrypt 1.8.1

=== Computer B ===
KeePassXC - Version 2.5.2
Revision: 62cda9d

Qt 5.13.2
Debugging mode is disabled.

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.18362

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.5

[darkwing1]

I just experienced a crash when deleting (by selecting 2 entries) from Recycle Bin, on 2.5.2
Ubuntu 18.04

The crashes still persist.