Comment 54 for bug 218434

Revision history for this message
Karl Dane (karl-rince) wrote : Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()

> - install gnome-devel
done

> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.

> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:

OPTIONAL DEPENDENCIES
   PAM: no
   DBus: 1.1.20
   HAL: no

CONFIGURATION
   SSH Agent: yes
   Root Certificates: none

BUILD
   Debug Build: no
   Unit Tests: no

> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.

Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.

Cheerio,

Karl

>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an 'assert(locvol != null)' should be added, but if 'null' is a valid retun then we need extra code to check it and handle it within this function, the simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>