[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Failed assertion in sockbuf.c
> On second thought, this could also be fixed in OpenLDAP. There's no reason
> it should behave this way. Try this patch on libldap/tls.c:
I tried this, and then I upgraded to 2.0.21, which seems to have the
patch included. Here's the new problem:
Reading pam_openldap.so.1
Reading libldap.so.2
Reading liblber.so.2
Reading libsasl.so.7
Reading libssl.so.0.9.6
dbx: warning: cannot demangle '__16__user_type_infoPCc'
dbx: warning: cannot demangle
'__14__si_type_infoPCcRC16__user_type_info'
dbx: warning: cannot demangle
'__17__class_type_infoPCcPCQ217__class_type_info9base_infoUi'
dbx: warning: cannot demangle '__13bad_exception'
dbx: warning: cannot demangle '__10bad_typeid'
Reading libcrypto.so.0.9.6
dbx: warning: cannot demangle
'__14__si_type_infoPCcRC16__user_type_info'
dbx: warning: cannot demangle
'__17__class_type_infoPCcPCQ217__class_type_info9base_infoUi'
dbx: warning: cannot demangle '__10bad_typeid'
dbx: warning: cannot demangle '__13bad_exception'
dbx: warning: cannot demangle '__16__user_type_infoPCc'
Reading libdb-3.3.so
Reading pam_unix.so.1
Reading libcmd.so.1
Reading nss_files.so.1
Reading nss_dns.so.1
signal SEGV (no mapping at the fault address) in ldap_int_tls_start at
0xfefd261c
0xfefd261c: ldap_int_tls_start+0x0018: ld [%i1], %l0
backtrace
=>[1] ldap_int_tls_start(0x37218, 0x0, 0x0, 0x0, 0x0, 0xffbeed0c), at
0xfefd261c
[2] ldap_start_tls_s(0x37218, 0x0, 0x0, 0xff194000, 0x11, 0xffbeed80),
at 0xfefd2ae0
[3] _open_session(0x35980, 0x35198, 0x0, 0xffffffff, 0xfffffff8,
0xffbef620), at 0xfeff3428
[4] _connect_anonymously(0x35980, 0xfeff7890, 0x35980, 0xfeff20ec,
0x0, 0x3598d), at 0xfeff3604
[5] _get_user_info(0x35980, 0x34d40, 0x1, 0xffbef740, 0x35f20,
0xffbef748), at 0xfeff41d8
[6] pam_sm_chauthtok(0x0, 0x234, 0x0, 0x34da0, 0x0, 0x0), at
0xfeff5460
[7] pam_chauthtok(0x0, 0xff3165c8, 0xff316000, 0x1, 0x1, 0x0), at
0xff3030b4
[8] main(0x34800, 0x35950, 0x34800, 0x34800, 0x0, 0x3225c), at 0x1304c