Control: forwarded 1120685 https://bugs.kde.org/show_bug.cgi?id=512485
On Sat, 22 Nov 2025 13:53:22 -0500 Boyuan Yang <[email protected]> wrote: > On Sat, 22 Nov 2025 13:46:50 -0500 Boyuan Yang <[email protected]> wrote: > > On Sat, 22 Nov 2025 22:02:13 +0500 Syed Shahrukh > > <[email protected]> wrote: > > > Yes I have now checked the bug #1120685, there seems to be > > > incompatibilities in ABI from sqlcipher 1 -> 2 and the kmymoney db > > > abstraction plugin is not ready for it. > > > > > > A sign is that preloading the older library solves the problem. > > > > > > There is only one removal of the symbol sqlcipher_exportFunc from 1->2 , > > > which is not used else kmymoney won;t be able to build. > > > > > > Presently the debug information is not sufficient to pinpoint the > > > problem. > > > > > > I checked out the source of kmymoney, where I found that kmymoney is > > > utilizing the QT library QSqlDatabase sqlcipher plugin for DB access. > > > > > > The sqlite plugin seems like a variant of > > > https://github.com/sjemens/qsqlcipher-qt5 which supports upto sqlcipher > > > 4.5.3, no updates since 2022. > > > > > > Plugin path within the source: kmymoney/plugins/sqlcipher > > > > > > Debugging the issue with kmymoney targeting the sqlcipher plugin will > > > likely be the way forward. > > > > Please find the backtrace in the attachment. > > When we look at the related source code: > > https://sources.debian.org/src/kmymoney/5.2.1-1/kmymoney/kmymoney.cpp#L1045 > > #ifdef ENABLE_SQLCIPHER > /* Issues: > * 1) libsqlite3 loads implicitly before libsqlcipher > * thus making the second one loaded but non-functional, > * 2) libsqlite3 gets linked into kmymoney target implicitly > * and it's not possible to unload or unlink it explicitly > * > * Solution: > * Use e.g. dummy sqlite3_key call, so that libsqlcipher gets loaded >implicitly before libsqlite3 > * thus making the first one functional. > * > * Additional info: > * 1) loading libsqlcipher explicitly doesn't solve the issue, > * 2) using sqlite3_key only in sqlstorage plugin doesn't solve the issue, > * 3) in a separate, minimal test case, loading libsqlite3 explicitly > * with QLibrary::ExportExternalSymbolsHint makes libsqlcipher >non-functional > */ > sqlite3_key(nullptr, nullptr, 0); > #endif > > ...should we continue in https://bugs.debian.org/1120685 instead of > https://bugs.debian.org/1121167 ? I will clarify something here: The symlink of /usr/lib/x86_64-linux-gnu/libsqlcipher.so.2 -> /usr/lib/x86_64-linux-gnu/libsqlcipher.so.3.50.4 is deliberate, correct, and won't trigger any issue. There are other existing examples in Debian, such as /usr/lib/x86_64-linux-gnu/libexiv2.so.28 -> /usr/lib/x86_64-linux-gnu/libexiv2.so.0.28.5 . The crash in kmymoney is due to kmymoney calling sqlite3_key(nullptr, nullptr, 0), which would return an error with older sqlcipher but segfault with newer sqlcipher. Calling sqlite3_key() itself with nullptr is problematic already. It is likely that kmymoney need to be patched. The bug has been reported at https://bugs.kde.org/show_bug.cgi?id=512485 . Thanks, Boyuan
signature.asc
Description: This is a digitally signed message part
