It's worth noting that shortly after experiencing this problem, I 
followed Grugnog's advice on this thread and checked out and compiled 
the latest version of gnome-keyring from subversion. Since then, I've 
had no issues, and gnome-keyring has worked like a charm. So it seems 
that, whether by accident or by design, this particular bug has been 
fixed. (I had a quick browse through its Changelog, but couldn't see 
anything relevant.)


Ovation1357 wrote:
> I've done a lot more work on this tonight and have the following
> information to submit:
> 
> Workaround
> ---------------
> This isn't really a workaround as you won't have any keyring functionality but at least you can log in. 
> 1) Enable login by disabling the gnome keyring PAM Module:
> # cp /etc/pam.d/gdm /etc/pam.d/gdm.old
> * Edit /etc/pam.d/gdm and delete all lines which reference 'pam_gnome_keyring.so' (Expect to find 2 lines)
> 2) Restart GDM or Reboot
> 3) Log in and you should get in, but obviously without the Keyring features.
> 
> Reproduction
> -----------------
> The occurrence of this bug seems most prevalent on USB, Compact Flash (attached via IDE) and SCSI based boot devices.
> 1) Use the Workaround above to be able to log in as a user.
> 2) Open a terminal
> 3) Run:
> # echo "<password>" | /usr/bin/gnome-keyring-manager -f --login
> N.B. <password> would normally be the user's password it crashes regardless of what you give it.
> 4) The keyring daemon should now list it's environment variables, a few messasges, a warning and then will visibly die  with a SEGV.
> NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option (as it gets called from the PAM module) will surpress all useful messages including the SEGV notification!! 
> 
> Debug
> --------
> I have attached gdb to gnome-keyring-manager and captured a full backtrace, register info and tread backtrace at the point of SEGV.  As I ran gdb pointed at the sources for keyring-daemon I have also captured 'list'.
> 
> On the console I get the following output:
>> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at /media/cdrom0
>> ** Message: adding removable location: volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at /
>>
>> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already registered at: /
>>
>> Program received signal SIGSEGV, Segmentation fault.
> 
> It seems that gnome-keyring-daemon is being screwed up while it tries to
> probe the HAL about storage - This might explain the apparent
> correlation between boot disk type and whether one sees the bug.
> 
> We die in hal_device_property() at gkr-location.c:324
> 
>  323                 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
>  324                 locvol->hal_volume = TRUE;
> 
> It seems that we might benefit from some kind of bounds check in this
> code as we seem to be taking it as gospel that 'locvol' will always
> return a valid address.
> 
> The SEGV happens while executing the instruction @ 0x080759c7 - This has
> been consistent throughout my old /var/log/messages files:
> 
> 0x080759c2 <hal_device_property+834>:	call   0x804f8e0 <g_hash_table_lookup@plt>
> 0x080759c7 <hal_device_property+839>:	movl   $0x1,0x14(%eax)
> 0x080759ce <hal_device_property+846>:	jmp    0x80758a5 <hal_device_property+549>
> 
> So in order to set locvol->hal_volume=TRUE we take $eax + 0x14,
> dereference it and write a gboolean there. This is fine for the first
> few volumes and $eax always = 0x80ca828 which I trust is the valid
> address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0
> (which helps me understand the fact the segfault is reported at
> '00000014' in /var/log/messages) - of course, 0x14 is not a vaild
> address.
> 
> The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name,
> name) returned NULL. An educated guess tells me that NULL is probably a
> valid return if 'name' wasn't found in the hash, but more investigation
> needs to be done in whether a simply "if ( locvol != null)" check can be
> added or whether g_hash_table_lookup() should never return NULL.
> 
> Anyway, I've included the tee output of my gdb session which will
> hopefully be of use to someone who knows more about the linux HAL.
> 
> If anyone wants me to gather any other information let me know, but I
> may need some instructions..
> 
> ** Attachment added: "gkd-debug-01:33:13.txt"
>    http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt
>