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 644407 - gkr_operation_block_and_unref(): assertion failed: (op->pending != pending)
gkr_operation_block_and_unref(): assertion failed: (op->pending != pending)
Status: RESOLVED FIXED
Product: libgnome-keyring
Classification: Core
Component: General
2.32.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
: 647189 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-10 15:53 UTC by Tomas Bzatek
Modified: 2019-02-22 11:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
backtrace (12.21 KB, application/octet-stream)
2011-03-10 15:53 UTC, Tomas Bzatek 		Details
another backtrace (13.35 KB, text/plain)
2011-03-10 15:53 UTC, Tomas Bzatek 		Details

Description Tomas Bzatek 2011-03-10 15:53:16 UTC 
Created attachment 183068 [details]
backtrace

originally reported downstream:
 https://bugzilla.redhat.com/show_bug.cgi?id=660407
 https://bugzilla.redhat.com/show_bug.cgi?id=665761
 https://bugzilla.redhat.com/show_bug.cgi?id=683707

Problem:
people seem to have issues with assertions thrown when an app is trying to access a keyring - see attached backtraces. This is 2.32 series libgnome-keyring, I haven't had troubles on 2.9 series. Also asked for more details in downstream bugreports.

Code:
judging from gvfskeyring.c:117, it's gnome_keyring_set_network_password_sync() call, not visible in the backtrace (optimized out). Or gnome_keyring_find_network_password_sync() respectively for the second backtrace. The gnome_keyring_is_available() call succeeds in both cases.
Comment 1 Tomas Bzatek 2011-03-10 15:53:34 UTC 
Created attachment 183069 [details]
another backtrace
Comment 2 Stef Walter 2011-03-10 16:14:13 UTC 
Thanks. This should fix the problem:

commit 84103a1d29e66ede966874e4af4b17706605cd48
Author: Stef Walter <stefw@collabora.co.uk>
Date:   Thu Mar 10 17:12:23 2011 +0100

    This assertion is vulnerable to corner conditions.
    
    In particular if the operation completes one pending call, unrefs it
    and creates another pending call, and the memory allocator decides
    to allocate that same memory for the next pending call, then this
    will assert in a bogus way.
Comment 3 Ross Lagerwall 2014-04-06 07:58:38 UTC 
*** Bug 647189 has been marked as a duplicate of this bug. ***