Comment 42 for bug 218434

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?