Bug 361372

Summary:	Trojita crashes with symbol lookup error against QtKeychain on startup
Product:	[Applications] trojita	Reporter:	Arthur Schiwon <blizzz>
Component:	Core	Assignee:	Trojita default assignee <trojita-bugs>
Status:	RESOLVED FIXED
Severity:	grave
Priority:	NOR
Version First Reported In:	0.6
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:	http://commits.kde.org/trojita/da070e70ca28761d58c1534e7bc88c9cd74cbd17	Version Fixed/Implemented In:
Sentry Crash Report:

Description Arthur Schiwon 2016-04-04 10:24:55 UTC

I have had Trojita set up since v 0.6. I decided to let the credentials be stored using QtKeychain. All worked fine until an update of QtKeychain to 0.6.0. Since then Trojita crashes on startup. Meanwhile QtKeychain is on 0.6.1. 



Reproducible: Always

Steps to Reproduce:
1. Configure Trojita 0.6 while running against QtKeychain 0.5. Quit Trojita.
2. Upgrade QtKeychain to 0.6.x
3. Launch Trojita

Actual Results:  
$ trojita 
trojita: symbol lookup error: /usr/lib/trojita/trojita_plugin_QtKeychainPasswordPlugin.so: undefined symbol: _ZN9QKeychain15ReadPasswordJob6setKeyERK7QString


Expected Results:  
Trojita starts successfully.

The Qt4 version of QtKeychain was dropped with 0.6.0.

Comment 1 Jan Kundrát 2016-04-04 11:08:40 UTC

Please ask your vendor (someone in ArchLinux likely?) to rebuild trojita after an update to qtkeychain. The latest qtkeychain update is apparently not ABI-compatible.

Comment 2 Pali Rohár 2016-04-04 11:19:37 UTC

On Monday 04 April 2016 11:08:40 Jan Kundrát via KDE Bugzilla  wrote:
> Please ask your vendor (someone in ArchLinux likely?) to rebuild trojita after
> an update to qtkeychain. The latest qtkeychain update is apparently not
> ABI-compatible.

That then looks like either qtkeychain project does not correctly
increased SOVERSION when introduced ABI incompatibility or package
maintainer did not propagated SOVERSION or correct dependency...

Comment 3 Thomas Lübking 2016-04-04 11:42:50 UTC

@Arthur, please run

   ldd /usr/lib/trojita/trojita_plugin_QtKeychainPasswordPlugin.so

I'd guess that it tries to resolve the minor version ("so.0.5") and fails for absence.

Comment 4 Jan Kundrát 2016-04-04 12:29:37 UTC

FYI, on my system at least and using the default build options, the main `trojita` executable does not link to QtKeychain. The trojita_plugin_QtKeychainPasswordPlugin.so does, and it links against a libqt5keychain.so.0.

There's an assert failure when the plugin fails to load, though, which might explain this bug in case the package is built with -DNEDEBUG (oh well):

ASSERT: "pluginInstance" in file /home/jkt/work/prog/trojita/src/Plugins/PluginManager.cpp, line 104

That's our bug.

Comment 5 Jan Kundrát 2016-04-04 12:48:49 UTC

https://gerrit.vesnicky.cesnet.cz/r/688

Comment 6 Arthur Schiwon 2016-04-04 12:56:34 UTC

@Thomas the desired output:

$  ldd /usr/lib/trojita/trojita_plugin_QtKeychainPasswordPlugin.so
        linux-vdso.so.1 (0x00007fff63982000)
        libtrojita_plugins.so => /usr/lib/libtrojita_plugins.so (0x00007f730e8cc000)
        libqt5keychain.so.0 => /usr/lib/libqt5keychain.so.0 (0x00007f730e6a4000)
        libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x00007f730dfda000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f730dc57000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f730da41000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f730d6a0000)
        libQt5DBus.so.5 => /usr/lib/libQt5DBus.so.5 (0x00007f730d416000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f730d1f9000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f730cfe3000)
        libicui18n.so.56 => /usr/lib/libicui18n.so.56 (0x00007f730cb66000)
        libicuuc.so.56 => /usr/lib/libicuuc.so.56 (0x00007f730c7cf000)
        libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x00007f730c569000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f730c364000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f730c056000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f730be4e000)
        libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007f730bdc7000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f730bac2000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x000055bc8e451000)
        libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f730b870000)
        libicudata.so.56 => /usr/lib/libicudata.so.56 (0x00007f7309e8d000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f7309c1d000)
        libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f7309a18000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f7309801000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f73095db000)
        liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007f73093c8000)
        libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f73090e6000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f7308ed2000)

Comment 7 Arthur Schiwon 2016-04-04 13:08:26 UTC

@Jan Also, I marked the package as "out of date". Waiting for the maintainer to pick it up.

Comment 8 Arthur Schiwon 2016-04-04 13:40:55 UTC

And finally, rebuilding manually makes Trojita function properly again. The UX fix is nevertheless appreciated – thank you :)

Comment 9 Jan Kundrát 2016-04-07 08:16:13 UTC

Git commit da070e70ca28761d58c1534e7bc88c9cd74cbd17 by Jan Kundrát.
Committed on 04/04/2016 at 12:44.
Pushed by gerrit into branch 'master'.

Do not assert on plugins which fail to load

A plugin might fail to load for example because someone has uninstalled
a required library, or because that library introduced an
ABI-incompatible change. In that case, Trojita either asserted or
outright crashed, which is a bit suboptimal ("the UX suffers" as they
say nowadays :) ).
Change-Id: Id31f25500a125080b3e67ea237de4589f4643495

M  +7    -0    src/Gui/Window.cpp
M  +5    -1    src/Plugins/PluginManager.cpp
M  +1    -0    src/Plugins/PluginManager.h

http://commits.kde.org/trojita/da070e70ca28761d58c1534e7bc88c9cd74cbd17