[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Hi Karl,
If you still have the stuff below installed, please can you rerun your
configure command and post back whether your build enables or disables HAL
support (you could just attach the configure output):
- install gnome-devel
- download gnome-keyring from svn
- configure with prefix = /usr
- install
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; }'
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Thanks for that Karl - this confirms my suspicions that you're not
compiling with HAL support so should not see this bug (but won't be able
to store keyrings on removeable media).
The code where the bug is is:
324 locvol-hal_volume = TRUE;
and earlier in the same file, the GkrLocationVolume struct is defined:
44 typedef struct _GkrLocationVolume {
45 GQuark volume_loc;
46 gchar *name;
47 gchar *prefix;
48 gchar *friendly;
49 gboolean hidden;
50 #ifdef WITH_HAL
51 gboolean hal_volume;
52 #endif
53 } GkrLocationVolume;
'hal_volume' is only included in the structure if we're compiling with
HAL support, so whatever code branches are called should never reach
line 324 in your configuration ( and if it did it would probably crash
with an undefined symbol error of some kind).
If I get some more free time I'll see if I can diagnose further - I assume that
I now need to submit proposed fixes or root-cause analysis to the upstream bug
at http://bugzilla.gnome.org/show_bug.cgi?id=530316
(This is my first involvement in any linux bugs so forgive me if I don't know
the process yet..)
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
I've been doing a bit of investigation into this where I can spare the time.
The gnome-keyring-daemon is getting started by the gdm PAM module:
gnome-keyring-2.22.1/pam/gkr-pam-module.c
In function setup_child()
Line
274 char *args[] = { GNOME_KEYRING_DAEMON, -d, --login, NULL};
then
Lines
329 /* Now actually execute the process */
330 execve (args[0], args, pam_getenvlist (ph));
I booted up and logged in on TTY1 then made and ran the following script:
#!/bin/bash
export PID=
while [[ $PID == ]]; do
PID=`pgrep keyring`
done
gdb -p $PID
Then I switched back to X on TTY7 and logged in. The big bonus of latching gdb
to the PID is that it actually halts execution. If we've been lucky with the
timing, the login screen freezes with the password hash greyed out.
Switching back to TTY1 we should find gdb waiting for instructions.
The problem is, that gnome-keyring-manager is a stripped binary and so the
stack-backtraces at any point have no symbol names (I hope I'm not
mis-understanding the meaning of a stripped binary!!!). I've tried including
the path to the source for GDM but I still can't get it to add any symbols
names.
I presume the lack of symbols is because it handles security. It may be
necessary to build a binary which is not stripped in order to get a meaningful
backtrace.
If I use 'cont' to continue execution, gdb stops twice with a Broken
Pipe signal and then another 'cont' returns that the program exited
normally. So I don't actually see a SEGV at all!
Perhaps someone who has more experience than me might be able to get
further with gdb?
--
gnome-keyring-daemon crashed with SIGSEGV
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
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 [EMAIL PROTECTED] 0x080759c7 hal_device_property+839: movl $0x1,0x14(%eax) 0x080759ce hal_device_property+846: jmp0x80758a5 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 '0014' 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 -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
I'm possibly noticing a trend here I've seen someone say that this bug happens on an Asus EePC which has a flash-based hard disk. Some of the above comments suggest that the bug occurs on a USB Flash drive booted with Hard but not on a real internal disk. And in my case, my laptop has some thermal issues and kills disks so I'm booting off an 8gb compact flash drive using a CF to IDE convertor. It seems too wacky to be true, but anyone confirm that they are seeing this bug whilst booted from a real disk? With reference to getting a proper backtrace, the only place I could find 'gnome-keyring-daemon' mentioned was in a binary file /etc/alternatives/x-session-manager so I can't find a script which I can hijack. I also tried writing an interposing script a /usr/bin/gnome- keyring-daemon but this never got loaded, so I'm clueless about how to get this to work. Given that another user has successfully downloaded gnome-dev and compiled a working keyring daemon into /usr I'm not hopeful that this problem will be very easy to recreate if we compiled debug binaries. However if someone from Ubuntu could supply an intrumented/debug binary which is built in the exact same environment as the failing version we might stand a chance?? Whichever way this goes, the bug has to be fixed at it's a show-stopper for Hopeless Hippo :-) -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
I've also hit the same bug after live upgrading from Ubuntu Gutsy to Hardy. The Live CD also works fine for me but GDM hangs on login for my disk environment. I removed the following line from /etc/pam.d/gdm : session optionalpam_gnome_keyring.so auto_start But obviously now, although my session starts, I have to manually enter things like my WiFi Key as the keyring manager isn't available. This is a pretty critical bug in my opinion as it cripples the graphical environment in Ubuntu - How did this get through beta?? N.B. I've just had to kill nm-applet as it's been using 90% of my CPU for most of the evening (didn't notice at first) - Not sure if my little PAM hack might have caused a different problem!! -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
