"Douglas, Ryan" <rdoug...@arbinet.com> writes:
> (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
> #3 0x00007f738dfefe10 in _pam_krb5_normal_prompter (context=0x0,
> data=0xb51890, name=0x7fff2e356668 "", banner=0x79df27 "", num_prompts=0,
> prompts=0x101010101010101)
> at prompter.c:409
Okay, so the dump is definitely way down inside libpam. The next question
is whether it's really libpam's fault, or are we passing it some bad
data. Please install the pam-debuginfo RPM that corresponds to the
pam version you have, and retry --- hopefully that will add a bit more
information to the stack trace.
(The debuginfo-install hint you got might help, though I'm not sure why
it's referencing audit-libs and not pam ... maybe this code isn't
actually in libpam?)
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
