openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Fwd: RE: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 12 Jun '13

12 Jun '13

Fix verified. -------- Original Message -------- Subject: RE: (ITS#7577) hdb and mdb derefere aliases differently Date: Wed, 12 Jun 2013 09:49:16 +0000 From: <Juergen.Sprenger(a)swisscom.com> To: <hyc(a)symas.com> I've checked with openldap-HEAD-95241fa.tar.gz, and it looks very good now. Identical results and very good performance. Looks like the cause was Gentoo ebuild. Done everything manually and no problems anymore. Juergen Sprenger -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, June 06, 2013 8:05 PM To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently Juergen.Sprenger(a)swisscom.com wrote: > File is transferred, name is mdb-test-juergen.tar.gz I've tested your data+config using both git master and RE24 and both give identical results for mdb and hdb. Seems something is wrong in your build. > > Juergen Sprenger > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 05, 2013 5:24 PM > To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH > Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently > > Juergen.Sprenger(a)swisscom.com wrote: >> Please use this public key: > > OK, you should be able to ssh/scp to juergen(a)ada.openldap.org now. >> >> ssh-dss AAAAB3NzaC1kc3MAAAEBANJd7abNzD+Ejrg33Vbl8TZm6hMpI8Y02XnwfhP6CMy6w2IVjyvMsuuLp1ioJvIvgVFSCwp6lO1FnbxNTzKyhcY+f2Apo7DDQtT+faZkhPRaTwG+hht5ZsxDAEPQVuGxk9jVzLOK8D4hqTs43P5zKQLmAtqnTompWwtmNH8qfHSiNRlr6lmbMQigWfGoRqJ6rdyRulfA1tYo4yRsprM5OA0E6tzBukMPtCNerXDjI8C1M0IopTVfcbqaDsO9Q66UntAIonI5sESEfTd6v8dUTb4Z2ZcanMVZpjlqKWdr/MCYBuCXR2oiDiens92S2M3U9zLtcW1tTAO+sWdcJvqeugUAAAAVAOtW0p5t0Hme1wsKmG6DpDyqkp5rAAABAFyTRnAkwT9DM7BxyMOefJtY8rhP4RylINbJqoJ2H36OiYFoblk9G0Si1qMhKvLBceoaqswSIFOaIpe0vGWydlInGuJOEZxKCuhbYT+oDGRfOZzLU4668HHeK9aoBHoo5xFb/YWDQVi0+XoQDX+CpCcauthknISuCFcWqpALwrTqj9MRL3wan5oUOzRyiQXmyCwvRgsxt4Ee42Za+ZXnqP0wj255OOPy4btI82Njhx/fPJbUNA1uIE4TnO6tMkeGwZ2T/io4K2Wrmq0anigEfTf4WJX8og0PDajI4htcwOCrzWTHrqDtmFGRii4uSAMjigMVg6rt7b7IfoMYN7UCG7sAAAEAKDivKfQjbvgglMoz5vhZs95EOSGm7R0rItfCQjUHcGtYjDagGsLRDXQn0DXLUxBsbOkiymouNl1d5x0+DLhKg8IDz+RbGCTJ6CJnCbu7OQanXVwTWpPBAL7mjA8Z0sts6weuXXLVZpbgdh8RBS11pH1eW/CXgdL05mFexkgMQ1i5V6L+KgEl+X3KtbRTTYBh0VCUJN2hRjMRCqzXbp6yyq6s+pzcCGBKymiVds! C! > Q5MKlfAI87 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+kLFaC5QaGex > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+QU > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+9enlA3N7W4w > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+7g > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+oqUDTaGa5Yv > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+y4 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+jNA== > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+dsa-key-200 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+71 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+012 >> >> Juergen Sprenger >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Thursday, May 30, 2013 3:03 PM >> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >> >> Juergen.Sprenger(a)swisscom.com wrote: >>> Sorry, company mail gateway removed the attached file. >>> >>> Where can I upload the mentioned archive? >> >> Send me an SSH public key and I'll set up an account on ada.openldap.org for you. >> >>> >>> Juergen Sprenger >>> >>> -----Original Message----- >>> From: Howard Chu [mailto:hyc@symas.com] >>> Sent: Wednesday, May 29, 2013 4:22 PM >>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>> >>> Juergen.Sprenger(a)swisscom.com wrote: >>>> The following file(s) has been removed because it violated the Swisscom security policy: >>>> >>>> ldap-hdb.sh >>>> ldap-mdb.sh >>>> >>>> >>>> Sorry, still can't get it working. >>>> >>>> Attached You will find my setup as a tarfile: >>> >>> There was no attachment on your email. >>>> >>>> mdb-test/ root/mdbtest.ldif # testdata >>>> mdb-test/ root/ldap-hdb.sh # script to switch config to hdb >>>> mdb-test/ root/ldap-mdb.sh # script to switch config to mdb >>>> >>>> mdb-test/etc/openldap/ # complete directory, but keys and certs removed >>>> mdb-test/etc/openldap/slapd.conf.hdb # slapd.conf using Berkeley DB >>>> mdb-test/etc/openldap/slapd.conf.mdb # slapd.conf using mdb >>>> >>>> mdb-test/etc/ldap.conf >>>> mdb-test/etc/ldap.conf.sudo link to >>>> mdb-test/etc/openldap/ldap.conf.sudo >>>> >>>> Juergen Sprenger >>>> >>>> -----Original Message----- >>>> From: Howard Chu [mailto:hyc@symas.com] >>>> Sent: Friday, May 17, 2013 6:24 PM >>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>> >>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>> Checked out 201ddbe3e4d8eb39830b96eefa559900952bc022, compiled, installed. >>>>> >>>>> # md5sum openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> 30f4e29eb7b4d0348f0e7ef100d0ba63 >>>>> openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> >>>>> But I still get different results: >>>> >>>> OK, try once more, commit a8c1438688f74081257d2aaba4e12814b9c8668f >>>> >>>>> >>>>> ## mdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> (result is empty) >>>>> >>>>> May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36262 (IP=0.0.0.0:389) May 17 14:30:54 openldap-dev >>>>> slapd[21001]: conn=1007 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 RESULT tag=97 err=0 text= May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:30:57 openldap-dev slapd[21001]: conn=1007 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=0 text= May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 op=2 UNBIND May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 fd=13 closed >>>>> >>>>> ## hdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> dn: uid=tgdspju1,ou=Person,dc=its,dc=scom >>>>> ... >>>>> >>>>> May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36267 (IP=0.0.0.0:389) May 17 14:33:06 openldap-dev >>>>> slapd[21089]: conn=1001 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 RESULT tag=97 err=0 text= May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:33:07 openldap-dev slapd[21089]: conn=1001 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=1 text= May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 op=2 UNBIND May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 fd=13 closed >>>>> >>>>> Juergen Sprenger >>>>> >>>>> -----Original Message----- >>>>> From: Howard Chu [mailto:hyc@symas.com] >>>>> Sent: Friday, May 17, 2013 1:34 PM >>>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH; >>>>> openldap-its(a)openldap.org >>>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>>> >>>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>>> tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 >>>>> >>>>> There was a followup commit also needed. >>>>> 201ddbe3e4d8eb39830b96eefa559900952bc022 >>>>> >>>>> Just get the latest. >>>>> >>>> >>>> >>> >>> >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7622) LMDB cursor _NEXT/_PREV
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Using MDB_PREV on an initialized empty DB (that was non-empty when the cursor was initialized) returns SUCCESS when it should return NOTFOUND. Bug introduced by commit 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 Fixed in c2cac4588a40480c020d320b544bc5f8e72adb11

1 0

(ITS#7621) LMDB mdb_stat() bug
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.32+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc In a0993354a603a970889ad5c160c289ecca316f81 txn_begin() was changed to defer reading a DB's root node until it was actually referenced, instead of always reading all DB root nodes at the beginning of a txn. Other ops already handled this case but mdb_stat() didn't, so if mdb_stat() was called for a named DB in a fresh txn that hadn't yet referenced any named DBs, it just returned zeroes in the stat structure. (The mainDB root node is always read so there was no issue there.) Fixed in bcb67dd22f06a7f7c85350bc548c50ccfc27dbaa

1 0

(ITS#7620) LMDB overflow page management
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Pages that are dirtied get pulled out of the freeDB. If they are freed in the same txn they should be returned to their original place in the freeDB instead of joining the current txn's list of freed pages. This is particularly important for overflow pages because otherwise we can consume a lot of overflow pages rapidly in some cases. Commit e7f6767ea815fe0ada1f95037dfdec176ec4d5bb in mdb.master is for this issue, but it needs additional fixes.

1 0

(ITS#7619) Unable to start OpenLDAP 2.4.35 with Oracle 10g
by lokesh.kumar1＠thomsonreuters.com 11 Jun '13

11 Jun '13

Full_Name: Lokesh Kumar Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.231.6.66) I am unable to start the LDAP on my linux machine with openldap-2.4.35 using back-sql with Oracle 10g as my datasource. I am able to connect to the Oracle database, but it fails to load the data on to the LDAP object schema. I am using the default sample data for Oracle RDBMS and the schema files which comes with the installable. Can you please look into this and let me know if I am missing something here? My sladp.config file looks like this: include <InstallFolder>/etc/openldap/schema/core.schema include <InstallFolder>/etc/openldap/schema/cosine.schema include <InstallFolder>/etc/openldap/schema/inetorgperson.schema pidfile <InstallFolder>/var/run/slapd.pid argsfile <InstallFolder>/var/run/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname OracleODBC-10g dbuser username dbpasswd password subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no The startup console output looks something like this: . . . 51b70f81 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 51b70f81 objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="call create_person(?)" create_keyval="" delete_proc="call delete_person(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" 51b70f81 create_proc="call create_person(?)" 51b70f81 delete_proc="call delete_person(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="call create_document(?)" create_keyval="" delete_proc="call delete_document(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" 51b70f81 create_proc="call create_document(?)" 51b70f81 delete_proc="call delete_document(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="call create_org(?)" create_keyval="" delete_proc="call delete_org(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" 51b70f81 create_proc="call create_org(?)" 51b70f81 delete_proc="call delete_org(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" 51b70f81 backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 backsql_oc_get_attr_mapping(): error executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 Return code: -1 51b70f81 <==backsql_load_schema_map() 51b70f81 backsql_db_open(): schema mapping failed, exiting 51b70f81 backend_startup_one (type=sql, suffix="dc=example,dc=com"): bi_db_open failed! (1) 51b70f81 slapd shutdown: initiated . . .

1 0

Re: (ITS#7618) pcache overlay does not allow the use of NOT ("!") in templates
by hyc＠symas.com 10 Jun '13

10 Jun '13

amoneger(a)cisco.com wrote: > Full_Name: Alex Moneger > Version: 2.4.35 > OS: centos 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > Hi, > > When trying to define a template which query contains a '!', slapd complains > about a syntax issue in the config file and refuses to start. This is by design. Read the Proxy Cache design paper. http://www.openldap.org/pub/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7618) pcache overlay does not allow the use of NOT ("!") in templates
by amoneger＠cisco.com 10 Jun '13

10 Jun '13

Full_Name: Alex Moneger Version: 2.4.35 OS: centos 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) Hi, When trying to define a template which query contains a '!', slapd complains about a syntax issue in the config file and refuses to start. This is because there seems to be a missing check for '!' in template_attrs() in pcache.c, so '!' char is passed to slap_bv2ad() which correctly errors out. i.e: May 27 20:53:53 centos63 slapd[44623]: line 71 (pcacheTemplate (&(gidNumber=)(objectClass=)(cn=*)(&(gidNumber=*)(!(gidNumber=)))) 0 3600) May 27 20:53:53 centos63 slapd[44623]: /etc/openldap/pcache.conf: line 71: unable to parse template: AttributeDescription contains inappropriate characters. I believe the use of "not" should be allowed in cacheable templates, since they appear to be a valid search filter definition as per RFC 2254. The fix is very easy. I cannot upload the diff to the ftp server, since it errors with space related errors when uploading the file. Content of the diff: --- openldap-2.4.35/servers/slapd/overlays/pcache.c 2013-03-28 15:41:51.000000000 +0000 +++ openldap-2.4.35/servers/slapd/overlays/pcache.c0 2013-05-27 21:27:20.847919253 +0100 @@ -523,7 +523,7 @@ allop = an_find( attrs, slap_bv_all_operational_attrs ); for (;;) { - while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' ) p1++; + while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' || *p1 == '!') p1++; p2 = strchr( p1, '=' ); if ( !p2 ) break; It can be applied this way if you consider this of any use: cd "${HOME}"/openldap-2.4.35 patch -p0 --verbose < ~/pcache.p0 Cheers, Alex

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by quanah＠zimbra.com 07 Jun '13

07 Jun '13

--On Friday, June 07, 2013 8:34 AM +0000 lily.zhang(a)emc.com wrote: > Hi > > Thank you for looking at it. > > A dump is generated when user login via LDAP account. > [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 OpenLDAP 2.4.16 is years old. Please confirm you see the issue using a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Hi Thank you for looking at it. A dump is generated when user login via LDAP account. 1. This is the code call in my code: NAVsint32 status = ldap_unbind_s( _ldapHandle ); 2. Below is the call stack and the content of _ldapHandle(dap 0x1b4b3d58). From the call stack, it seems call stack corrupts in function call ldap_unbind_s(). 3. Issue can be solved by restarting the process, but issue can reproduced once in while in the user's environment. 4. Please let me if you need other material about this issue. 0:112:x86> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213] 1fd5c2c4 0cafd615 eedd5f4e 1fd5c35c 1fd5c4ec SecurityProvider!ecom::caprovider::OpenLDAPLogin::_disconnect+0x1e [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 1344] 1fd5c2e0 0caf98dd eedd5956 1fd5c324 1fd5c324 SecurityProvider!ecom::caprovider::OpenLDAPLogin::~OpenLDAPLogin+0x35 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 198] 1fd5c4f8 0cada203 1fd5c63c 1fd5c64c 1fd5c5d4 SecurityProvider!ecom::caprovider::OpenLDAPAuthLoginContext::login+0x37d [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldapauthlogincontext.cpp @ 159] 1fd5c604 0cabd419 1fd5c63c 1fd5c64c 1fd5c724 SecurityProvider!ecom::caprovider::NaviCA_LDAPFeature::AuthenticateUser+0x203 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\generated\mynavica_ldapfeature.cpp @ 1415] 1fd5c634 0ca668db 4aab2ba0 00000006 00000007 SecurityProvider!NaviSec_SecurityAdmin::AuthenticateCAUser+0x69 [z:\naviservices\providers\securityprovider\generated\navisec_securityadminmethods.cpp @ 4211] 1fd5c734 0ca63e3b 1fd5c85c 4aab2ba0 00000006 SecurityProvider!NaviSec_Authentication::CanUserAccess+0x1bb [z:\naviservices\providers\securityprovider\generated\navisec_authenticationmethods.cpp @ 154] 0:112:x86> dt -r8 ldap 0x1b4b3d58 Openldap!ldap +0x000 ld_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x004 ld_options : ldapoptions +0x000 ldo_valid : 2 +0x004 ldo_debug : 0 +0x008 ldo_tm_api : timeval +0x000 tv_sec : -1 +0x004 tv_usec : 0 +0x010 ldo_tm_net : timeval +0x000 tv_sec : 30 +0x004 tv_usec : 0 +0x018 ldo_version : 3 +0x01c ldo_deref : 0 +0x020 ldo_timelimit : 0 +0x024 ldo_sizelimit : 0 +0x028 ldo_tls_ctx : (null) +0x02c ldo_tls_connect_cb : (null) +0x030 ldo_tls_connect_arg : (null) +0x034 ldo_tls_info : ldaptls +0x000 lt_certfile : (null) +0x004 lt_keyfile : (null) +0x008 lt_dhfile : (null) +0x00c lt_cacertfile : (null) +0x010 lt_cacertdir : (null) +0x014 lt_ciphersuite : (null) +0x018 lt_crlfile : (null) +0x01c lt_randfile : (null) +0x020 lt_protocol_min : 0 +0x058 ldo_tls_mode : 0 +0x05c ldo_tls_require_cert : 0 +0x060 ldo_tls_impl : 0 +0x064 ldo_tls_crlcheck : 0 +0x068 ldo_defludp : (null) +0x06c ldo_defport : 389 +0x070 ldo_defbase : (null) +0x074 ldo_defbinddn : (null) +0x078 ldo_def_sasl_mech : (null) +0x07c ldo_def_sasl_realm : (null) +0x080 ldo_def_sasl_authcid : (null) +0x084 ldo_def_sasl_authzid : (null) +0x088 ldo_sasl_secprops : sasl_security_properties +0x000 min_ssf : 0 +0x004 max_ssf : 0x7fffffff +0x008 maxbufsize : 0xffffff +0x00c security_flags : 0x11 +0x010 property_names : (null) +0x014 property_values : (null) +0x0a0 ldo_refhoplimit : 5 +0x0a4 ldo_sctrls : (null) +0x0a8 ldo_cctrls : (null) +0x0ac ldo_rebind_proc : (null) +0x0b0 ldo_rebind_params : (null) +0x0b4 ldo_nextref_proc : (null) +0x0b8 ldo_nextref_params : (null) +0x0bc ldo_urllist_proc : (null) +0x0c0 ldo_urllist_params : (null) +0x0c4 ldo_conn_cbs : (null) +0x0c8 ldo_booleans : 0 +0x0d0 ld_lberoptions : 1 +0x0d4 ld_errno : 0 +0x0d8 ld_error : (null) +0x0dc ld_matched : (null) +0x0e0 ld_referrals : (null) +0x0e4 ld_msgid : 4 +0x0e8 ld_requests : (null) +0x0ec ld_responses : (null) +0x0f0 ld_nabandoned : 0 +0x0f4 ld_abandoned : (null) +0x0f8 ld_cache : (null) +0x0fc ld_defconn : (null) +0x100 ld_conns : (null) +0x104 ld_selectinfo : (null) -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2013$BG/(B6$B7n(B7$BF|(B 16:19 To: Zhang, Lily (USD) Subject: Re: (ITS#7617) Stack issue Openldap!ldap_unbind_s *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#7617. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#7617) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7617) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=7617 Please remember to retain your issue tracking number (ITS#7617) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Full_Name: Zhang, Lily Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.159.144.57) Here is the code we call ldap_unbind_s(). void OpenLDAPLogin::_disconnect() { if (_ldapHandle == NULL) { return; } // ldap_unbind_s will free up the space // allocated for the LDAP handle NAVsint32 status = ldap_unbind_s( _ldapHandle ); if (status != LDAP_SUCCESS) { return; } _ldapHandle = NULL; } Here is the call stack, eip become an invalid pointer. If the process was restarted, issue was disappeared, but it may be reproduced sometimes later. Please help me have a look that whether is a bug that fixed in the latest version. *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs