"Douglas, Ryan" <rdoug...@arbinet.com> writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x0000000000559624 in pam_passwd_conv_proc ()
> Missing separate debuginfos, use: debuginfo-install
> audit-libs-1.7.13-1.fc11.x86_64
> (gdb) bt
> #0 0x0000000000559624 in pam_passwd_conv_proc ()
> #1 0x00007f738dfeedd8 in _pam_krb5_conv_call (pamh=<value optimized out>,
> messages=0xb51780, n_prompts=0, responses=0x7fff2e356668) at conv.c:99
> #2 0x00007f738dfefb38 in _pam_krb5_generic_prompter (context=<value
> optimized out>, data=0x7fff2e357fe0, name=<value optimized out>,
> banner=<value optimized out>, num_prompts=1,
> prompts=<value optimized out>, suppress_password_prompts=1) at
> prompter.c:330
Actually, now that I look more closely at that stack trace,
pam_passwd_conv_proc *is* a Postgres function --- so the core dump
is happening when libpam calls us back. (I wonder why gdb failed
to present any information about it? Are you using a stripped
postgres executable?)
In a quick look at the source for pam_passwd_conv_proc, the only
very plausible explanation for why it would segfault in isolated
cases seems to be that the initial sanity check on the passed-in
message status might be assuming more than it should --- in particular
it would obviously dump core if msg is null or msg[0] is null.
I am thinking that maybe, when the KDC is Active Directory and there's
no password supplied already, libpam makes additional calls to the
conv_proc with parameter values that we're not prepared to handle.
Can you add additional debug printouts or step through the code
and verify what's happening there?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
