FW: Failed assertion in sockbuf.c

["Howard Chu" <hyc@highlandsun.com>]

In looking at this again, I see that my previous patch to tls.c is unnecessary.
The ld_sb handle should have been a valid pointer, ldap_create always sets it
when it creates the LDAP* handle. I believe the real problem is as I pointed
out originally, they have mixed the Solaris LDAP libraries with OpenLDAP. Most
likely the LDAP* handle was created by the Solaris library, and all the other
functions came out of the Solaris library. Since the Solaris library doesn't
provide any start_tls functions, this function was resolved from the OpenLDAP
library, and it (rightfully) blows up at that point.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Howard Chu
Sent: Tuesday, January 15, 2002 4:00 PM
To: Clint Adams
Cc: Mark de Jong; OpenLDAP-software@OpenLDAP.org
Subject: RE: Failed assertion in sockbuf.c


There is some other problem here. The LDAP* handle has not been initialized
properly, it should not have NULL pointers in the sockbuf or default connection
fields by the time it gets this far. Fixing this will require debugging
pam_ldap, and that is not a topic for this mailing list.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Clint Adams [mailto:clint@gcfm.net]
> Sent: Tuesday, January 15, 2002 2:40 PM
> To: Howard Chu
> Cc: Clint Adams; Mark de Jong; OpenLDAP-software@OpenLDAP.org
> Subject: 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
>