After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 616512 - Crash in gnome_keyring_is_available, e_passwords_init at e-passwords.c line 1273
Crash in gnome_keyring_is_available, e_passwords_init at e-passwords.c line 1273
Status: RESOLVED FIXED
Product: libgnome-keyring
Classification: Core
Component: General
2.30.x
Other All
: High critical
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
evolution[pop] evolution[passwords]
: 617807 622603 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-04-22 13:07 UTC by aalarcon
Modified: 2019-02-22 11:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30



Description aalarcon 2010-04-22 13:07:39 UTC
What were you doing when the application crashed?
Check Email.


Distribution: Debian squeeze/sid
Gnome Release: 2.28.2 2009-12-18 (Debian)
BugBuddy Version: 2.30.0

System: Linux 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10706901
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: gnome-alternative
GTK+ Modules: gnomebreakpad, canberra-gtk-module

Memory status: size: 266186752 vsize: 266186752 resident: 44859392 share: 25448448 rss: 44859392 rss_rlim: 18446744073709551615
CPU usage: start_time: 1271940946 rtime: 831 utime: 798 stime: 33 cutime:2 cstime: 7 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

[Thread debugging using libthread_db enabled]
[New Thread 0xa8905b70 (LWP 8350)]
[New Thread 0xaa108b70 (LWP 8349)]
[New Thread 0xaa909b70 (LWP 8348)]
[New Thread 0xab90bb70 (LWP 8346)]
[New Thread 0xafcf7b70 (LWP 8345)]
[New Thread 0xb0cf9b70 (LWP 8344)]
[New Thread 0xb32feb70 (LWP 8342)]
[New Thread 0xb1cfbb70 (LWP 8341)]
[New Thread 0xa9907b70 (LWP 8340)]
[New Thread 0xb3c7db70 (LWP 8077)]
[New Thread 0xac349b70 (LWP 8076)]
[New Thread 0xb24fcb70 (LWP 7764)]
[New Thread 0xb04f8b70 (LWP 7763)]
[New Thread 0xb482cb70 (LWP 7753)]
[New Thread 0xb502db70 (LWP 7752)]
0xb77d5424 in __kernel_vsyscall ()

Thread 10 (Thread 0xa9907b70 (LWP 8340))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    from /lib/i686/cmov/libpthread.so.0
  • #2 _L_lock_881
    from /lib/i686/cmov/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/i686/cmov/libpthread.so.0
  • #4 segv_redirect
    at main.c line 441
  • #5 <signal handler called>
  • #6 magazine_cache_pop_magazine
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gslice.c line 691
  • #7 thread_memory_magazine1_reload
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gslice.c line 748
  • #8 IA__g_slice_alloc
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gslice.c line 825
  • #9 IA__g_slice_alloc0
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gslice.c line 845
  • #10 ??
    from /usr/lib/libgnome-keyring.so.0
  • #11 gnome_keyring_is_available
    from /usr/lib/libgnome-keyring.so.0
  • #12 e_passwords_init
    at e-passwords.c line 1273
  • #13 ep_msg_new
    at e-passwords.c line 480
  • #14 e_passwords_get_password
    at e-passwords.c line 1424
  • #15 get_password
    at mail-session.c line 191
  • #16 camel_session_get_password
    at camel-session.c line 383
  • #17 pop3_try_authenticate
    at camel-pop3-store.c line 484
  • #18 pop3_connect
    at camel-pop3-store.c line 606
  • #19 camel_service_connect
    at camel-service.c line 364
  • #20 camel_session_get_service_connected
    at camel-session.c line 280
  • #21 mail_tool_get_inbox
    at mail-tools.c line 70
  • #22 fetch_mail_exec
    at mail-ops.c line 298
  • #23 mail_msg_proxy
    at mail-mt.c line 522
  • #24 g_thread_pool_thread_proxy
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gthreadpool.c line 315
  • #25 g_thread_create_proxy
    at /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/glib/gthread.c line 1893
  • #26 start_thread
    from /lib/i686/cmov/libpthread.so.0
  • #27 clone
    from /lib/i686/cmov/libc.so.6

	Inferior 1 [process 7728] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]


---- Critical and fatal warnings logged during execution ----

** evolution **: file gkr-operation.c: line 350 (gkr_operation_request): should not be reached 
** evolution **: file gkr-operation.c: line 350 (gkr_operation_request): should not be reached 


----------- .xsession-errors (14 sec old) ---------------------
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
(exe:5656): Gdk-WARNING **: XID collision, trouble ahead
--------------------------------------------------
Comment 1 Akhil Laddha 2010-04-23 03:56:57 UTC
could be similar to bug 616146
Comment 2 Akhil Laddha 2010-05-06 03:29:47 UTC
*** Bug 617807 has been marked as a duplicate of this bug. ***
Comment 3 Sebastien Bacher 2010-06-21 16:24:16 UTC
reassigning to gnome-keyring, from IRC discussion "gnome_keyring_is_available() is calling gkr_operation_unref() -followed by- gkr_operation_block()"

"gnome_keyring_is_available (void)
...
	gkr_operation_unref (op);
	return gkr_operation_block (op) == GNOME_KEYRING_RESULT_OK;
..."
Comment 4 Stef Walter 2010-06-21 17:31:13 UTC
This is about a crash, so I don't think it's similar to #616146. However a better stack trace (with symbols of libgnome-keyring) will lead us to the bottom of this.

The stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols of libgnome-keyring?

Please see http://live.gnome.org/GettingTraces for more information on how to do so and then post that stack trace here. Thanks in advance!
Comment 5 Sebastien Bacher 2010-06-21 21:43:42 UTC
there is some similar crashes on https://bugs.launchpad.net/bugs/530760

http://launchpadlibrarian.net/48113986/gdb-evolution.txt has a stacktrace with some debug symbols

one duplicate has some valgrind logs with invalid read:
http://launchpadlibrarian.net/50559413/valgrind.log.gz
http://launchpadlibrarian.net/50575393/valgrind.log.gz
http://launchpadlibrarian.net/50591767/valgrind-logs-evolution.tar.gz

isn't using "op" after calling unref an issue?
Comment 6 Stef Walter 2010-06-22 02:45:16 UTC
Yes, calling unref before blocking is a symptom of a systemic problem with the libgnome-keyring API (which predates me). The API is pretty broken with regards to multiple threads.

The new Secret Service DBus API, does not suffer from these problems. However there is not yet a helper client side helper library for it.

In order to try and patch things up and keep apps working, I've committed a temporary fix specifically to gnome_keyring_is_available() in the gnome-2-30 branch. Please test, and verify that this fixes the problem:

commit 78f80470e8f2318334d1022925bb91966e6a192f
Author: Stef Walter <stef@memberwebs.com>
Date:   Tue Jun 22 02:38:32 2010 +0000

    Stop gap fix for threading problem in gnome_keyring_is_available()
    
     * This will be fixed more fully in master.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=616512
Comment 7 Stef Walter 2010-06-22 02:48:38 UTC
Better fix committed to master (for libgnome-keyring 2.31.x and 2.32.x)

commit c359ce893958d1a2dcb4aa9b958a38002b8836d6
Author: Stef Walter <stef@memberwebs.com>
Date:   Tue Jun 22 02:46:06 2010 +0000

    Try to fix broken usage on multiple threads in libgnome-keyring
    
     * This has to do with operations completing in the mainloop thread
       before the async function which starts them returns in another
       thread.
     * Some use cases are just not fixable. We print a message throwing
       our hands up in despair.
     * The async functions will try to return NULL if an operation completes
       before the function that starts it return.

Thanks everyone for digging up all the information surrounding this issue. Much appreciated.
Comment 8 Akhil Laddha 2010-06-24 14:12:52 UTC
*** Bug 622603 has been marked as a duplicate of this bug. ***