Bug 307910

Created attachment 162096 [details]
backtrace

Created attachment 162097 [details]
NetworkManager log

Created attachment 162098 [details]
iwlist wlan0 scan output

Created attachment 162099 [details]
messages

Created attachment 162110 [details]
backtrace generated by bugbuddy with debug info packages installed

Created attachment 162111 [details]
backtrace manualy generated with  debuginfo packages are installed

Calvin, I believe you though this was fixed with the new gnome-keyring?

gnome-keyring-manager-2.18.0-57
gnome-keyring-manager-debuginfo-2.18.0-57
gnome-keyring-debuginfo-2.19.91-4
gnome-keyring-2.19.91-4

I had another bug (which I can't seem to find) that referenced this bug and reported that once the keyring was fixed, the problem in this bug was also fixed.  It appears that the keyring issue was not the only issue here.  I don't really have any further information.

I have the same issue. Nm-applet should ask for the keyring password to read the encryption key, but it just crashes when I click on any wireless network shown in the applet.

Same issue in beta3 (fresh install) and with 3945 Intel card. Do you need more log ?

Tambet, any hints for Scott would be great.

It's the same bug Calvin mentions, I can't seem to find it either. gnome-keyring returns OK to notify successful key retrieval but the list of found keys is NULL. I guess I'll have to add a workaround and not trust gnome-keyring.

It doesn't seem to be a generic bug - at least it worked for cthiel (my live CD test had different issues with NM, that are undoubtful live CD specific). So what is the ETA?

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

(Well, it's kinda obvious since the trouble seems to be in gnome-keyring - this
happens only on encryption-protected WiFi; unencrypted WiFi (e.g. at the labs
conf) works fine, at least for me. Also, the first time after installation I
selected a WPA-protected network it worked too - that was before the keyring
got set up.)

I removed the novellvpn NM stuff and it works now.

That was a hunch....

ignore comment #17 it still crashes.

Here the decent stack trace I have,

Enjoy


[Switching to Thread 0x412a0d60 (LWP 27709)]
nmi_dbus_get_network_key_callback (result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x82aa6c8)
    at applet-dbus-info.c:143
143                     nm_gconf_wso_set_key (gconf_wso, found->secret, strlen (found->secret));
(gdb) where
#0  nmi_dbus_get_network_key_callback (result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x82aa6c8)
    at applet-dbus-info.c:143
#1  0x40784b1d in find_items_reply (op=0x81a1c80) at gnome-keyring.c:2004
#2  0x40786037 in operation_io (io_channel=0x82aa658, cond=<value optimized out>, callback_data=0x81a1c80)
    at gnome-keyring.c:539
#3  0x410ccbdd in g_io_unix_dispatch (source=0x828dbc0, callback=0x40785f60 <operation_io>, user_data=0x81a1c80)
    at giounix.c:162
#4  0x4109d446 in IA__g_main_context_dispatch (context=0x80a0a78) at gmain.c:2061
#5  0x410a07e2 in g_main_context_iterate (context=0x80a0a78, block=1, dispatch=1, self=0x8075088) at gmain.c:2694
#6  0x410a0bc7 in IA__g_main_loop_run (loop=0x80dc998) at gmain.c:2898
#7  0x40958a34 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#8  0x0804fe31 in main (argc=0, argv=0x0) at main.c:74
#9  0x41142fe0 in __libc_start_main () from /lib/libc.so.6
#10 0x0804fca1 in _start ()
(gdb) 

==14873== 
==14873== Invalid read of size 4
==14873==    at 0x805D649: nmi_dbus_get_network_key_callback (applet-dbus-info.c:143)
==14873==    by 0x478EB1C: find_items_reply (gnome-keyring.c:2004)
==14873==    by 0x4790036: operation_io (gnome-keyring.c:539)
==14873==    by 0x50D7BDC: g_io_unix_dispatch (giounix.c:162)
==14873==    by 0x50A8445: g_main_context_dispatch (gmain.c:2061)
==14873==    by 0x50AB7E1: g_main_context_iterate (gmain.c:2694)
==14873==    by 0x50ABBC6: g_main_loop_run (gmain.c:2898)
==14873==    by 0x4962A33: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1106.0)
==14873==    by 0x804FE30: main (main.c:74)
==14873==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14873==

That's the only Valgrind error that occur beside ORBit's usual stuff.

The NULL pointer for found items is definitely confirmed.  Why its NULL in some cases is curious though.

my guess is that there is not password in that keyring.... and the case where the keyring isn't setup is not the same. If I kill gnome-keyring it work, but then disconnect when it can't save to the keyring... (hint: this is IMHO a bug too)

I have run strace to the keyring-daemon....


Process 28487 attached - interrupt to quit
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
poll(

NOW nm-applet is started and will ask for the WPA password



[{fd=4, events=POLLIN}, {fd=3, events=POLLIN, revents=POLLIN}, {fd=6, events=POLLIN}], 3, -1) = 1
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
accept(3, {sa_family=AF_FILE, path=@}, [2]) = 8
mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002d000
mlock(0x4002d000, 16384)                = 0
mmap2(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40447000
mprotect(0x40447000, 4096, PROT_NONE)   = 0
clone(child_stack=0x406474b4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40647bd8, {entry_number:6, base_addr:0x40647b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x40647bd8) = 28569
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}], 3, -1) = 1
futex(0x40647bd8, FUTEX_WAIT, 28569, NULL) = 0
close(8)                                = 0
read(6, "\252", 1)                      = 1
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0xbfd613df, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
poll(



Somewhere in these traces, nm-applet has crashed.

To answer JP question on IRC, the file descriptor 6 is likely to be the socket used for the IPC with the keyring daemon.

It seems as though between gnome-keyring 0.8 and 2.19.x, gnome-keyring
changed the result code if no objects were found, in 0.8
gnome_keyring_daemon:op_find_execute we have:

if (access_requests == NULL) {
        gnome_keyring_proto_add_uint32 (result, GNOME_KEYRING_RESULT_DENIED);
} else {
        gnome_keyring_proto_add_uint32 (result, GNOME_KEYRING_RESULT_OK);
}

ie basically if no items were found (so no access requests) or no
accessible secrets were found, you'd get a DENIED back.  In 2.19.1
gkr-daemon.c:op_find we have:


/* No items given access to */
if (ctx.nfound > 0 && ctx.items == NULL) 
        gkr_buffer_add_uint32 (result, GNOME_KEYRING_RESULT_DENIED);


ie DENIED is only returned if some items were found and none could be
accessed.

NM 0.6.x releases at least assume OK == found items because of 0.8 and
previous.

Mailed upstream to see if this change was intentional or not.

Submitted a fix for it.