Comment 7 for bug 292791

  Nov 2 18:48:53 my_username-desktop gdm[5928]: pam_nologin(gdm:auth): cannot determine username

This error in particular suggests a problem unrelated to the contents of /etc/pam.d/common-auth. The standard contents of /etc/pam.d/gdm are:

auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth optional pam_gnome_keyring.so

That means pam_nologin.so is failing to recover the username, and the authentication stack short-circuits at that point, before we ever look at anything in /etc/pam.d/common-auth. So whatever this problem is, it appears to be unrelated to pam_smbpass or any other contents of /etc/pam.d/common-auth.

  Nov 2 18:55:59 my_username-desktop gdm[5829]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=my_username

This next error is the one cited before, and points to a simple login failure.

  Nov 2 20:45:40 my_username-desktop login[5708]: PAM bad jump in stack

This, as you mentioned, could be a result of trying to edit the config.

And these lines:

  Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session opened for user root by (uid=0)
  Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session closed for user root

correspond to periodic cron sessions, not anything related to your logins.

> I also tried to reproduce the bug, by setting auth-common and auth-password back to the "old"
> version from my first post. In a second terminal, I tried to do a 'sudo -s' and got this in Terminal:
> Segmentation fault.

This is probably the most promising avenue of investigation. Do you get any log messages in /var/log/auth.log that match up with this segfault? If not, can you reproduce it when running 'sudo -s' from a root shell? (This would let us get a backtrace from sudo using gdb)