Bug 757478

Created attachment 537064 [details]
File: dso_list

Created attachment 537065 [details]
File: build_ids

Created attachment 537066 [details]
File: maps

Created attachment 537067 [details]
File: smolt_data

Created attachment 537068 [details]
File: xsession_errors

Created attachment 537069 [details]
File: var_log_messages

Created attachment 537070 [details]
File: backtrace

*** Bug 758898 has been marked as a duplicate of this bug. ***

*** Bug 760701 has been marked as a duplicate of this bug. ***

*** Bug 760712 has been marked as a duplicate of this bug. ***

One possible cause might be that dbus threading should be initialized in gnome-shell. Since libgnome-keyring does this (if not already done) there may be issues with threading being swapped out while dbus calls are active.

But the more I look at this, it seems related to bug #773269.

It's likely this is the same code path failing, just doing it at a later point (after on_complete_later() is invoked and during cleanup of the GSource, which calls operation_unref().

Would need to reproduce in order to identify the source of the problem better. Obviously memory corruption is a source of suspicion for both these bugs because the stacks just don't make sense.

The backtrace and code makes it seem like the operation is already freed.

I notice a lot of the api in gnome-keyring.c ends with gkr_operation_pending_and_unref() which returns an operation that can be cancelled with gnome_keyring_cancel_request which calls gkr_operation_complete_later.  This latter function does the g_idle_add_full that triggers the on_complete_later shown in the backtrace.  The source id of the g_idle_add_full call is never recorded.  So, I believe that if multiple calls to  gkr_operation_complete_later are made on the same request, multiple idles will be dispatched. Each one refs the operation though. So it seems like for this bug to hit, some code would have to 1) cause gkr_operation_complete_later to get called more than once in quick succession and 2) their would have to be an unref bug.

A quick grep in the gnome-shell code shows shell-network-agent.c does a gnome_keyring_find_itemsv call that calls get_secrets_keyring_cb on completion.  The bottom of that function does g_hash_table_remove which calls gnome_keyring_cancel_request.  So the shell code cancels the request immediately after getting a response.  That might satisfy 1) (not sure, didn't keep digging), but it's not immediately clear how 2) would be happening regardless.

(In reply to comment #12)
Your analysis is correct, but I've looked over the unref code and can't see anything wrong that would cause a double free. In addition we should be seeing malloc errors when freeing memory 

> A quick grep in the gnome-shell code shows shell-network-agent.c does a
> gnome_keyring_find_itemsv call that calls get_secrets_keyring_cb on completion.
>  The bottom of that function does g_hash_table_remove which calls
> gnome_keyring_cancel_request.  So the shell code cancels the request
> immediately after getting a response.  That might satisfy 1) (not sure, didn't
> keep digging), but it's not immediately clear how 2) would be happening
> regardless.

Well, get_secrets_keyring_cb sets closure->keyring_op to NULL right at the top, which would keep gnome_keyring_cancel_request() from being called in cases the gnome_keyring_find_itemsv() operation completes.

Even if the request currently in a callback was being cancelled, the gkr_operation_set_result() conditional in gkr_operation_complete() and gkr_operation_complete_later() prevent the request from 'completing' twice.

It's a shame it's using slices for GkrOperation, if we were using malloc memory we could rule out or confirm double free easily.

note it doesn't have to be a double free(), just use-after-free().

on_complete_later has

if (!g_queue_is_empty (&op->callbacks)) on_complete (op)

on_complete has

cb = g_queue_pop_tail (&op->callbacks);
assert (cb)

(which is failing)

the assertion can blow if op is freed, since g_queue_is_empty looks at the queue head and g_queue_pop_tail looks at the queue tail and there's no gaurantee the head and tail are consistent with each other after op is freed.

So this problem could be explained by the operation getting unref'd too many times before the idle fires.

I was setting up the Wireless Network in NetworkManager when the problem occurred unknown to me.

backtrace_rating: 4
Package: gnome-shell-3.2.1-2.fc16
OS Release: Fedora release 16 (Verne)

Created attachment 555863 [details]
File: backtrace

(In reply to comment #14)
> note it doesn't have to be a double free(), just use-after-free().

Right but the use-after-free would result in a double free as further down in that function we would free the same memory again. But in any case that seems like what's happening. I'm just at a loss as to how it's happening and have been looking over the code, and can't identify the mismatched references (yet).

If this is reproducible for anyone reading this, and you can run gnome-shell with the environment variable "GKR_DEBUG=all" that would be great. libgnome-keyring produces a bunch of output with that environment variable that would be helpful in tracking this down.

i don't know

backtrace_rating: 4
Package: gnome-shell-3.2.1-2.fc16
OS Release: Fedora release 16 (Verne)

Created attachment 557136 [details]
File: backtrace

I think this commit might fix the issue:

http://git.gnome.org/browse/libgnome-keyring/commit/?id=627895abba1b34fbd436968f775134cc5f62754c

In particular this bit: 


diff --git a/library/gkr-operation.c b/library/gkr-operation.c
index d3792b3..fc3ecc9 100644
--- a/library/gkr-operation.c
+++ b/library/gkr-operation.c
@@ -218,8 +218,7 @@ gkr_operation_set_result (GkrOperation *op, GnomeKeyringResult res)
 {
 	g_assert (op);
 	g_assert ((int) res != INCOMPLETE);
-	g_atomic_int_compare_and_exchange (&op->result, INCOMPLETE, res);
-	return g_atomic_int_get (&op->result) == res; /* Success when already set to res */
+	return g_atomic_int_compare_and_exchange (&op->result, INCOMPLETE, res);
 }
 
This commit is also worthwhile tracking this issue if the problem continues:

http://git.gnome.org/browse/libgnome-keyring/commit/?id=767a3a755c10081694c19b62bbcd76d440e27673

Should I close this bug, as the above commit is a likely fix. Or is there anyone who would like to take a moment to check if this fixes your issue? I realize though this is hard to reproduce.

*** Bug 773269 has been marked as a duplicate of this bug. ***

o problema aconteceu durante a tentativa de conexão da wifi, a algum tempo que acontece isso nem consigo conectar meu notebook nas redes wifi, só da certo com cabo de rede.

backtrace_rating: 4
Package: gnome-shell-3.2.2.1-1.fc16
OS Release: Fedora release 16 (Verne)

Created attachment 573836 [details]
File: backtrace

o fato de não conseguir conectar wi-fi resultou no erro.

backtrace_rating: 4
Package: gnome-shell-3.2.2.1-1.fc16
OS Release: Fedora release 16 (Verne)

Created attachment 574329 [details]
File: backtrace

Network Manager could not connect to wireless, and kept asking for password.  A stack of about 20 password dialogs built up while I was away.  I dismissed them, connected again, and it crashed.

backtrace_rating: 4
Package: gnome-shell-3.2.2.1-1.fc16
OS Release: Fedora release 16 (Verne)

Created attachment 574371 [details]
File: backtrace

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.