GNOME Bugzilla – Bug 608510
assertion failure when item is not in keyring
Last modified: 2019-02-22 11:46:56 UTC
Created attachment 152619 [details] [review] Possible fix When trying to open a password-protected document in evince where the password hasn't been stored in the keyring yet, I get the following assertion failure: ERROR:gnome-keyring.c:105:prepare_get_secret: assertion failed: (path) Evince uses gnome_keyring_find_password_sync to lookup the document pasword. The attached patch appears to fix this, however, I'm not familiar at all with the libgnome-keyring codebase, so I don't know whether the patch makes sense.
*** Bug 608709 has been marked as a duplicate of this bug. ***
Could somebody review the change? It's a blocker to get gnome-keyring 2.29 in ubuntu lucid now
Bug #599000 is actually the same as this one. To reproduce: start mission-control-5 built with gnome-keyring support. It will assert immediately: Starting program: /usr/lib64/mission-control-5 [Thread debugging using libthread_db enabled] ** ERROR:gnome-keyring.c:105:prepare_get_secret: assertion failed: (path) Program received signal SIGABRT, Aborted. 0x00007ffff67ce955 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing debug package(s), you should install: libgcrypt-debug libgpg-error-debug pcre-debug telepathy-glib-debug zlib-debug (gdb) thread apply all bt
+ Trace 220556
Thread 1 (Thread 0x7ffff7fcb700 (LWP 2253))
Thanks for the patch Jürg. Sorry, I've had a fix for this, but didn't have time to test it before pushing it into master. Finally committed this in libgnome-keyring, with slightly different behavior to the above patch (returns a NULL password).
*** Bug 599000 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Sorry, I've had a fix for this, but didn't have time to test it before pushing > it into master. Finally committed this in libgnome-keyring, with slightly > different behavior to the above patch (returns a NULL password). Apparently, we need to return GNOME_KEYRING_RESULT_NO_MATCH and not GNOME_KEYRING_RESULT_OK (with NULL password): at least mission-control relies on this behavior to correctly work, so changing this would be an ABI change.
Created attachment 153911 [details] [review] Change the return value
You're right. For some reason I thought this was in a different code path. Your patch looks good. However the tests need updating: ERROR:test-keyrings.c:505:test_find_no_password: assertion failed (GNOME_KEYRING_RESULT_OK == res): (0 == 9) GTester: last random seed: R02Scbb60db271e758b19d246e7f36c8041c Run 'make check' and/or library/tests/run-auto-test Due to bug fixes, the tests require the latest gnome-keyring to be installed, not just built.
*** Bug 611025 has been marked as a duplicate of this bug. ***
Does this change reopen the problem? http://git.gnome.org/browse/libgnome-keyring/commit/?id=18affdaadb8c71bfc4092d9281b03c9833027c6a
Created attachment 157484 [details] [review] Fix regressed regression You're right. Sorry about that. The original design was for gnome_keyring_find_password and friends to return NULL, and the code in the gnome-2-28 library attests to that. However because of the behavior of the daemon, this never actually happened. So here's a patch that changes this back. We now again return GNOME_KEYRING_RESULT_NO_MATCH.
Thanks Stef, I've committed your patch ;-)